You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
Description
Right now it's possible to append prefixed additional commands to a block of run/sudo statements with
prefix()
(and special cases likecd()
), 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.would execute:
However, this naive approach would fall down when combined with
prefix()
, because this:would turn into this:
and NOT this, which some users might need/expect:
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 executingprefix()
-- 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 theirprefix()
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 usevars()
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
The text was updated successfully, but these errors were encountered: