You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
What problem are you trying to solve?
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, sincedevbox 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 recommendeddirenv
setup anymore.The text was updated successfully, but these errors were encountered: