Prefer runtime env values over .env values

[NAR8789]

• inherit environment variables from runtime environment in run and start, but not export
• prefer variables defined in runtime environment over those in .env or via -e
• fixes Read environment variables directly from CLI command #707 Read environment variables directly from CLI command
• partially fixes .env load behaviour at odds with dotenv #702 .env load behaviour at odds with dotenv
  • inherits environment from runtime environment, and prefers runtime environment to .env, similar to dotenv
  • differs from dotenv in that dotenv always prefers earlier-defined variables, even within listed files. Foreman's existing behavior was to prefer later-defined variables in listed files, so I have kept this ordering for now. This would be easy to reverse if preferred

[ddollar]

This looks good, but can you please rebase it with recent merged changes?

[NAR8789]

@ddollar thanks for taking a look! Rebased.

[scalp42]

@ddollar any chance to take a look at this PR? Thank you in advance!

[hez]

This is a great feature, we were just looking for this. Thank you @NAR8789 👍

[NAR8789]

Thanks @scalp42, thanks @hez!

Reference for anyone else coming to this PR: There is a workaround in the discussion in Issue #561. tl;dr start foreman with foreman start -e /dev/null.

This suppresses foreman's .env-loading behavior altogether (thus letting you pass through whatever env vars you like at foreman invocation time). This works for my application because the application itself uses dotenv, so I get fully-compliant dotenv behavior.

I suspect actually that most applications are like this, in that the right thing to do is suppress foreman's .env behavior entirely.

(also, sorry for the notification spam--I posted with the wrong account earlier)

[scalp42]

@NAR8789 thanks a lot for the workaround.

Can you confirm that if you use -e /dev/null it doesn't just nullify the ENV variables all together? Meaning dotenv won't still work either way?

[NAR8789]

@scalp42 sure! try the following:

mkdir foreman-nullenv
cd foreman-nullenv
echo 'env: env' > Procfile    # create a procfile that just prints your env
foreman start                 # run it!

here you should get output corresponding to your exported shell env. You can play around with creating a .env to see foreman's usual undesriable override behavior.

Then try with -e /dev/null. This will confirm that -e /dev/null does not just nullify environment

foreman start -e /dev/null

Here you should get your original env again. If this nullified environment, you'd get no output.

Try playing around with exporting additional env vars, or specifying env vars on the same line as foreman start. All these should work more or less intuitively, and should prove foreman start -e /dev/null just disables forman's env munging.

---

In actual development, I point foreman at a file containing an explanatory comment (instead of /dev/null), to give developers context about the weird foreman invocation. So... invoke foreman as foreman start -e .env.noop, and .env.noop looks like:

# this file purposely empty, to prevent foreman from altering environment

[scalp42]

@NAR8789 thanks a lot for the help! Much appreciated 🙇

[Intrepidd]

Hi ! Any status on this one ? I chased a bug for hours before finding that it was due to this foreman behaviour :(

Thanks !

[scalp42]

@ddollar any chance to get this merged?