.env load behaviour at odds with dotenv

[PhilT]

With dotenv if you have a var in .env and also have an environment variable of the same name it will use the environment variable over the .env defined one. This allows you to define a .env but then override it in certain environments with environment variables.

With foreman, however, it seems .env always overrides any environment variables. I think it makes sense to mirror what dotenv does.

For my specific use case I'm running up foreman within a docker container to start some sidekiq processes as well as the app server. However, as the .env contains a MQ_HOST var of localhost I can't override it in the environment of the docker-compose.yml to point to the rabbitmq docker service as would be expected when executing the command directly.

This allows a default local development configuration as well as a docker based development config.

[arcreative]

I can't even get my processes to start with dotenv gem. Being able to run both is preferable for me since rake tasks need the environment vars as well, and that's obviously not getting run through foreman.

[arcreative]

Nevermind, I had an old version of foreman somehow... but I'm still +1 on this and #711 :-)

[andrewmcodes]

@PhilT Is this still an issue?

[PhilT]

@andrewmcodes Take a look at the referenced PR above. There is a workaround.

[stevenharman]

The workaround mentioned in #711 is to pass the --env=/dev/null option, which effectively causes foreman to load an empty file. This then allows dotenv (and/or dotenv-rails) to take over and load the hierarchy of files, with overrides, etc…. I don't love this workaround, but it makes sense.

I wonder if we can improve it by adding some sort of sticky configuration to disable .env loading all together? That way we could set it once, and then not have to remember to pass the --env=/dev/null every time going forward. Thoughts?