Consider shell env var support

[bitprophet]

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

[bitprophet]

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]

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]

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