Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Future planning: how to manage global arguments #695

Closed
Fizzadar opened this issue Nov 1, 2021 · 4 comments
Closed

Future planning: how to manage global arguments #695

Fizzadar opened this issue Nov 1, 2021 · 4 comments
Assignees
Labels
discussion Issues that need opinions!
Milestone

Comments

@Fizzadar
Copy link
Member

Fizzadar commented Nov 1, 2021

pyinfra has a number of global @operation/@deploy arguments, these are "magic" in that they are extracted before other arguments are passed into the operation/deploy function. This means that these functions cannot use arguments with the same name as global arguments.

While this works OK for builtin operations, where this issue can be managed, it's a disaster for 3rd party operations and deploys. It effectively bocks additional global arugments being added (such as docker_user, which would be very useful).

# Currently:
files.file(
    name='Create a file as the pyinfra user using sudo',
    path='/home/pyinfra/sudo_testfile',
    sudo_user='pyinfra',
    env={'PATH': '/home/pyinfra/.local/bin'},
)

# Could become:
with operation_args(sudo_user='pyinfra', env={'PATH': '/home/pyinfra/.local/bin'}):
    files.file(
        name='Create a file as the pyinfra user using sudo',
        path='/home/pyinfra/sudo_testfile',
    )

# OR, make a simple rule that _ prefixed commands are reserved:
files.file(
    name='Create a file as the pyinfra user using sudo',
    path='/home/pyinfra/sudo_testfile',
    _sudo_user='pyinfra',
    _env={'PATH': '/home/pyinfra/.local/bin'},
)

# OR, a dictionary for all such commands
files.file(
    name='Create a file as the pyinfra user using sudo',
    path='/home/pyinfra/sudo_testfile',
    operation_args={
        'sudo_user': 'pyinfra',
        'env': {'PATH': '/home/pyinfra/.local/bin'},
    },
)

# OR, nicer(?) style
files.file(
    name='Create a file as the pyinfra user using sudo',
    path='/home/pyinfra/sudo_testfile',
    operation_args=dict(
        sudo_user='pyinfra',
        env={'PATH': '/home/pyinfra/.local/bin'},
    ),
)

Currently leaning towards the dict (option 3+4), with the final option style wise, only because it's easier to read (IMO, very subjective) and is the closest match to the current way.

@Fizzadar Fizzadar added the discussion Issues that need opinions! label Nov 1, 2021
@Fizzadar Fizzadar added this to the v3 milestone Nov 1, 2021
@Fizzadar
Copy link
Member Author

From: #585 (comment)

This might be the right point to also start supporting Solaris'/Illumos' pfexec, and maybe unify the interface of using them? Instead of having various use_login, usepassword, preserve_env, remove the specific name, and provide a new parameter like e.g. priv_tool that can be set to one of the supported methods. Then I could write in my deploys files.file(..., priv_tool=doas, use_priv_login=True).

This way, when I adapt the deploy to another OS, or simply when I have to switch to sudo because I started to need to use some of its features, I only have change it at one point. That point could even be somewhere central, instead of in every single operation.

@Gaming4LifeDE
Copy link
Contributor

I'd prefer option 3 I think just because option 4 is more verbose where it doesn't need to be. On the other hand, another solution could be just to prefix like Ansible does (e.g. pyinfra_sudo_user)

@Fizzadar Fizzadar modified the milestones: v3, v2 Feb 24, 2022
@Fizzadar Fizzadar self-assigned this Feb 24, 2022
@Fizzadar
Copy link
Member Author

_ prefixed gloal arguments is now part of v2, with backwards compatibility until v3.

@Fizzadar
Copy link
Member Author

Fizzadar commented Apr 9, 2022

Released in v2!

@Fizzadar Fizzadar closed this as completed Apr 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Issues that need opinions!
Projects
None yet
Development

No branches or pull requests

2 participants