Many development setups I work with use more than one .env file - most commonly one that contains values that are shared among all developers and thus committed into GIT and one that is private and thus excluded from .gitignore.
devbox currently does not support such kind of setups, since devbox generate direnv does not allow to pass multiple env files.
What solution would you like?
direnv already allows to do that using by just listing multiple .env files in .envrc like this:
If the command devbox generate direnv would allow to specify --env-file multiple times and put them in the given order into the generated .envrc file and also output them in the given order when the option --print-envrc is used, then everything would just work as expected.
Alternatives you've considered
Passing multiple --env-file arguments has been tried but that did not work as it just uses the last given one.
A workaround is to manually write the .envrc file but that means a lot of extra manual work in every affected git repository and the risk to lose the good integration by not conforming to the recommended direnv setup anymore.
What problem are you trying to solve?
Many development setups I work with use more than one
.envfile - most commonly one that contains values that are shared among all developers and thus committed into GIT and one that is private and thus excluded from.gitignore.devboxcurrently does not support such kind of setups, sincedevbox generate direnvdoes not allow to pass multiple env files.What solution would you like?
direnvalready allows to do that using by just listing multiple.envfiles in.envrclike this:If the command
devbox generate direnvwould allow to specify--env-filemultiple times and put them in the given order into the generated.envrcfile and also output them in the given order when the option--print-envrcis used, then everything would just work as expected.Alternatives you've considered
Passing multiple
--env-filearguments has been tried but that did not work as it just uses the last given one. A workaround is to manually write the.envrcfile but that means a lot of extra manual work in every affected git repository and the risk to lose the good integration by not conforming to the recommendeddirenvsetup anymore.