.env load behaviour at odds with dotenv
PhilT opened this issue · comments
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.
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.
Nevermind, I had an old version of foreman somehow... but I'm still +1 on this and #711 :-)
@PhilT Is this still an issue?
@andrewmcodes Take a look at the referenced PR above. There is a workaround.
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?