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

Setting Shell_Env before running prefix #1135

Closed
wbashir opened this issue May 21, 2014 · 6 comments
Closed

Setting Shell_Env before running prefix #1135

wbashir opened this issue May 21, 2014 · 6 comments
Labels

Comments

@wbashir
Copy link

@wbashir wbashir commented May 21, 2014

I would like to run and set my shell_env before the execution of the prefix. It looks like my shell env is never set in the example below:

with shell_env(ENV1="TEST"):
    with prefix(". myapp"):
          run("echo $ENV2")

I expected my shell_env to be set but my prefix runs first. I know this because the prefix commands uses the environment variables and will prompt for them if not set?

@wbashir
Copy link
Author

@wbashir wbashir commented Jun 3, 2014

I have to run another prefix and export my environment variables directly as a workaround. Any help ?

@bitprophet bitprophet added Bug labels Aug 4, 2014
@cmattoon
Copy link

@cmattoon cmattoon commented Dec 21, 2014

This code generates the following final command:

from fabric.api import *

def test1():
    with shell_env(ENV1="IT WORKS",ENV2="TEST2"):
        with prefix("echo $ENV1"):
            run("echo $ENV2")

/bin/bash -l -c "echo \$ENV1 && export ENV2=\"TEST2\" ENV1=\"IT WORKS\" && echo \$ENV2"

Changing this in fabric/operations.py obtains the desired output for this bug, but I'm not sure how this will affect other use cases.

         wrapped_command = _shell_wrap(
             _prefix_env_vars(_prefix_commands(command, 'remote')),
             shell_escape,
             shell,
             _sudo_prefix(user, group) if sudo else None
 )
    wrapped_command = _shell_wrap(
             _prefix_commands(_prefix_env_vars(command), 'remote'),
             shell_escape,
             shell,
             _sudo_prefix(user, group) if sudo else None
    )

/bin/bash -l -c "export ENV2=\"TEST2\" ENV1=\"IT WORKS\" && echo \$ENV1 && echo \$ENV2"

This passed the existing tests, minus the two below that failed in master as well.

======================================================================
ERROR: abort() should print 'Fatal error' plus exception value
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/home/tyler/git/fabric/tests/mock_streams.py", line 74, in inner_wrapper
    ret = func(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/fudge-1.0.3-py2.7.egg/fudge/patcher.py", line 148, in method_call
    patched_obj.restore()
  File "/usr/local/lib/python2.7/dist-packages/fudge-1.0.3-py2.7.egg/fudge/patcher.py", line 320, in restore
    delattr(self.orig_object, self.attr_name)
AttributeError: aborts
======================================================================
ERROR: warn() should print 'Warning' plus given text
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/home/tyler/git/fabric/tests/mock_streams.py", line 74, in inner_wrapper
    ret = func(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/fudge-1.0.3-py2.7.egg/fudge/patcher.py", line 148, in method_call
    patched_obj.restore()
  File "/usr/local/lib/python2.7/dist-packages/fudge-1.0.3-py2.7.egg/fudge/patcher.py", line 320, in restore
    delattr(self.orig_object, self.attr_name)
AttributeError: warnings
----------------------------------------------------------------------
Ran 392 tests in 122.098s
FAILED (errors=2)
cmattoon added a commit to cmattoon/fabric that referenced this issue Dec 21, 2014
Reverses the order in which `shell_env` and `prefix` are applied to a command.
@wbashir
Copy link
Author

@wbashir wbashir commented Dec 21, 2014

@cmattoon Thanks for investigating, I have been looking for a cleaner solution. @bitprophet thoughts on this ?

@cmattoon
Copy link

@cmattoon cmattoon commented Dec 21, 2014

I can also add a kwarg (ala #1208) if needed.

@bitprophet
Copy link
Member

@bitprophet bitprophet commented Jan 5, 2015

Yea offhand I don't see how this is anything other than an oversight in the implementation of shell_env. And since it's just sugar, it shouldn't seriously break things for anybody in a way they cannot fix themselves.

@bitprophet
Copy link
Member

@bitprophet bitprophet commented Jan 5, 2015

Closing to roll into #1241, thanks @cmattoon!

@bitprophet bitprophet closed this Jan 5, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants