Is your feature request related to a problem? Please describe.
My employer has a corporate proxy that requires an extra certificate for SSL signing. My approach to this issue in the past has been to use .envrc that exports these variables in a top-level directory, but I've quickly realized that this doesn't work if I have another .envrc in a sub-directory.
Describe the solution you'd like
Direnv already traverses parent directories to find the most recent .envrc file. It seems like it should be possible to simply traverse the entire directory structure from child to parent, and apply each .envrc in reverse in order to merge them together into one environment that respects nested precedence.
This means that if an environment variable is exported with different values in a parent and child directory, then the child directory takes precedence.
Describe alternatives you've considered
I do understand that adding direct shell environment variable is appropriate in this context. However, there are other cases where I share environment variables between projects, and there's no way to have a structure like
dir/.envrc (export FOO="FOO")sub_dir/.envrc (export BAR="BAR")$FOO is "FOO" and $BAR is "BAR"Similarly, it should also be possible to do
dir/.envrc (export FOO="FOO")$FOO = "FOO", $BAR is undefinedsub_dir/.envrc (export FOO="FOO2"; export BAR="BAR")$FOO is "FOO2", $BAR is "BAR"Any thoughts on this would be welcomed, or if there's some other way I can accomplish this I'd love to hear about it!
if you control all the .envrc files, then the easiest is to add the source_up command from the stdlib in the child .envrc files. This will search up the file hierarchy and source the first file that it find.
That works for the SSL certificate case — is there a way to make that continue recursively (without putting source_up in all of them)? I’d still like to see that kind of scoped behavior if possible.
Not at the moment. In the current design, the env sourcing is done explicitly in each file. What you are thinking of would require direnv to know about the whole hierarchy somehow and make that external.
Would you mind mentioning this in README? I had to dig quite a lot to end up with source_up suggestion.
It works btw, awesome!
I don't know that the README is the right place. If it becomes too big, people just skip over it and don't read it.
Maybe it's time for somebody to write a user guide?
Most helpful comment
if you control all the
.envrcfiles, then the easiest is to add thesource_upcommand from the stdlib in the child.envrcfiles. This will search up the file hierarchy and source the first file that it find.