No way to specify remote environment variables

[max-arnold]

from fabric import task

cmd = '''python3 -c "import os; print(os.environ.get('ENV'))"'''

@task
def test_env(ctx):
    ctx.run(cmd, replace_env=False, echo=True, env={'ENV': 'production'})

@task
def test_prefix(ctx):
    with ctx.prefix('ENV=production'):
        ctx.run(cmd, replace_env=False, echo=True)

First task prints None because the default sshd install has AcceptEnv LANG LC_* and nothing else (see #1744 (comment)):

% fab -H example.com test-env

python3 -c "import os; print(os.environ.get('ENV'))"
None

Second one fails due to && (although it probably used to work, see #1744 (comment)):

% fab -H example.com test-prefix

ENV=production && python3 -c "import os; print(os.environ.get('ENV'))"
None

The value of replace_env flag does not matter.

[ciarancourtney]

One workaround is to use export in the prefix case:

ENV=production && python3 -c "import os; print(os.environ.get('ENV'))"
None

export ENV=production && python3 -c "import os; print(os.environ.get('ENV'))"
production

[bitprophet]

Think this needs to roll into #1744, please follow along there for comments.

[bitprophet]

Sorry, #1752. Ugh. So many tickets. No wonder I never get anything done, I'm spending all my time closing duplicates 😢

[bitprophet]

Still suffering ticket confusion. Insofar as this issue is about "most servers only have AcceptEnv LANG LC_* set by default", it needs to stay open.

---

Offhand, while I don't like the "turn the requested env into a bunch of INLINE=settings LIKE=this BEFORE=the command" approach, I don't see anything that will work better.

Main question is thus how to add this to the API; the released-as-2.0 behavior is to use "proper" env manipulation, so we cannot simply change it, or we'll break for anyone who's happily trucking along with a more permissive AcceptEnv (as uncommon as that probably is).

I'm thinking most obvious is to add a configuration setting (maybe also a keyword argument, but this feels a lot like it really wants to be config-only; it's effectively a property of the remote host or connection) like, say, ssh_env_inline (a bit mouthy but anything I can come up with is gonna be at least as bad).

[bitprophet]

Have this working, as inline_ssh_env (yes, opposite of above) with one caveat: kicking the can regarding any escaping of env var values, even ones with spaces or other shell metachars in them. Nothing is quoted, backslashed, or etc. This has the following properties:

• Not doing it half-assed means not having to support that half-assed attempt forever. Cough, fabric 1's general approach to commands at large, cough.
• We retain the right to find some bulletproof shell escaping related library function and apply it later (with, as always, some opt-in setting to activate it). It's easier to do this than to undo a naive, only-partly-works implementation (see first line item).
• Users can insert their own quoting, escaping, etc in the env dict's values, and it will arrive untouched at the remote end. They may still have issues depending on the details and their remote shell, but we will not be getting in their way at all.
  • Again, we have a lot of experience where a half-baked auto-escape system actually makes life worse for any use cases it fails to cover.

[bitprophet]

Enough of the Travis run is green that I am declaring this Done For Now. It'll be out in 2.3.

[bitprophet]

Grump, just realized that this isn't the absolute best way to do this; it breaks down for nontrivial shell commands, eg FOO=bar command1 && command2 only applies FOO to command1.

Going to VERY quickly address this as if it were a bug and pop out another release.

[bitprophet]

2.3.1 now out with that fix. Hopefully that's the only big embarrassing mistake with this 😝 I skimmed the rest of v1's shell_env() contextmanager and the rest of what it does isn't very applicable (extra logic around $PATH that we don't currently offer, that sort of thing).