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

Consider shell env var support #263

Closed
bitprophet opened this Issue Aug 19, 2011 · 3 comments

Comments

Projects
None yet
1 participant
@bitprophet
Member

bitprophet commented Aug 19, 2011

Description

Right now it's possible to append prefixed additional commands to a block of run/sudo statements with prefix() (and special cases like cd()), i.e. something_refactored && individual_commands_go_here -- but what still requires manual string manipulation is environment variables, i.e. SOMETHING=refactored individual_commands_go_here.

Naive implementation would simply ape prefix(), be a single context manager, and add env vars to the individual commands run inside the block, so e.g.

with shell_env(X='y'):
    run('foo')

would execute:

$ X='y' foo

However, this naive approach would fall down when combined with prefix(), because this:

with prefix('do something'):
    with shell_env(X='y'):
        run('foo')

would turn into this:

$ do something && X='y' foo

and NOT this, which some users might need/expect:

$ X='y' do something && X='y' foo

And because we can't have nice persistent multi-command shell environments, using e.g. export is out of the question.

That said, it should definitely be possible to reference the data stored up by shell_env() when executing prefix() -- doing so would just be a slightly more complicated implementation, and it's possible some users might not want the shell env vars applied to their prefix() commands. (Though I'd argue the common case would be the one where we apply the env vars to both prefixes and final commands.)


Finally, make sure sudo() is appropriately handled, though looking at our current method of building up command strings, I don't think we'd need to do anything special.


Note that I'm using shell_env() as a placeholder name here, though it's not a bad name and avoids the pitfalls of A) confusing people w/r/t Fabric's env var versus shell env vars, and B) you can't just use vars() as that's a Python builtin.

That said, name suggestions are welcome.


Originally submitted by Jeff Forcier (bitprophet) on 2010-12-01 at 03:11pm EST

@ghost ghost assigned bitprophet Aug 19, 2011

@bitprophet

This comment has been minimized.

Member

bitprophet commented Aug 19, 2011

Matthew Swasey (mig) posted:


Regarding making sure variables are available to all commands in the pipeline, you could use export or even set automatic exporting, e.g.:

with prefix('do something'):
    with shell_env(V='foo', X='bar'):
        run('foo')

would turn into:

export V="foo" X="bar" && do something && foo

or:

set -a && V="foo" X="bar" && do something && foo

Both these forms are POSIX compliant IIRC (they work in sh, bash, dash, ksh at least) but may not work in all shells (e.g. csh).


on 2010-12-02 at 05:13am EST

@bitprophet

This comment has been minimized.

Member

bitprophet commented Aug 19, 2011

Jeff Forcier (bitprophet) posted:


Hah, I had totally forgotten that that's a valid way of doing this, but you're quite right. That would likely simplify the implementation a bit too -- should make it just another special-case of prefix (albeit one where it must always be placed at the beginning of the commands list). Using a Fab env-var dict and .update()-ing it should also deal with nesting issues reasonably well.


on 2010-12-08 at 01:16pm EST

@bitprophet

This comment has been minimized.

Member

bitprophet commented Oct 13, 2011

#438 is a pull request implementing at least part of this functionality.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment