The current workaround is to add dotenv in the .envrc. It's part of the stdlib and loads the .env file.

I am not against extending direnv to support that scenario.

Do you want me to look to integrate that ?

Yeah, have a look. We have a config.toml file now where the option could be introduced. I haven't really thought out the best approach to handle this yet. Maybe template .envrc files matches to specific path patterns could be nice.

Would love to have this as well. Either that, or the option to globally configure direnv (in ~/.direnvrc I guess) to look for .env instead of .envrc. Will allow for other environment related tools (dotenv and EnvKey) that look for .env to all work in harmony.

I think that we need a template system that can load pre-defined .envrc files when specific files are found. The lookup would then change from for each folder up until root, look for .envrc to for each folder up until root, look for .envrc and a list of other files that maps to templates. This would make each prompt a bit more costly as it increases the number of stat() syscalls but should still be reasonable.

config.toml

[templates]
.env = env.envrc
shell.nix = nix.envrc

where env.envrc and nix.envrc would live under ~/.config/direnv/templates`.

env.envcr would contain dotenv and nix.envrc use nix.

I'm a bit wary of complicating direnv but that seems like a useful extension.

I am interested in having direnv load a different configuration file as well. I'm using .envrc to hold 12-factor app configuration parameters, and it works well in principle, but I do not like the fact that the resulting configuration parameters for the app are stored in a hidden file. Although checking in these files violates the principle that these variables should never be checked into code, I balance that against the idea of infrastructure as code that should be checked in.

If I could instead specify which visible (as opposed to hidden) file to load environment values from, then I could store the non-secret configuration information in them in a way that is obvious and maintainable. Real secrets like API keys will still have to be handled differently, but at least I could avoid hiding important configuration information in hidden files.

one approach is to add this to the .envrc:

[[ -f .envrc.private ]] && source_env .envrc.private

that gives a level of extensibility for local overrides

I wanted to load a ".env" file with a different name (or multiple of them) and the source_env function wasn't working (probably because they're just Unix conf-like files (key=value)), so I found this solution:

set -a
. <conf file>
set +a

Where set -a auto-exports definitions in the file being sourced, and set +a turns off this functionality (as described in this SO answer)

I looked through the stdlib, but didn't find any other clear solution for it. Just wanted to leave this here as it pops up when searching for solutions and "load different env file" was what I wanted to do too, though maybe with a different intent :)

NOTE: the solution offered by @zimbatm is not secure, checksum of .envrc.private is not verified, i.e you can make changes to .envrc.private and it will be loaded happily by direnv

is there method that also checks for checksum?:

direnv: error .envrc.private is blocked. Run `direnv allow` to approve its content.

@zimbatm @glensc what if you call dotenv instead of source_env? The following works (even interpolation... a nice touch!):

.env files

ls .env*
.env  .env.dev  .env.local  .envrc

.envrc

dotenv
[ -f ".env.${APP_ENV}" ] && dotenv ".env.${APP_ENV}"
dotenv .env.local

@bmeynell Old thread, I know, but loading a .local file using dotenv <file> does not seem to trigger any "allow"-prompting for me whenever the .local file is modified. 🤔 It's not a huge issue for me (since it's an uncommitted file that will never go into the repo), but still, it could be an issue for others.

@bmeynell Old thread, I know, but loading a .local file using dotenv <file> does not seem to trigger any "allow"-prompting for me whenever the .local file is modified. 🤔 It's not a huge issue for me (since it's an uncommitted file that will never go into the repo), but still, it could be an issue for others.

Also, another issue: if you are doing more complex things like integrating with the 1Password CLI, the dotenv <file> approach doesn't work , for things like this:

export SOME_VARIABLE=$(op read op://Private/item-name/password)

You have to rely on the source_env approach for that to work. But as noted above ☝️, both of these seem to behave the same in my case, in terms of "no prompting"... (Haven't re-tested since I wrote the above comment 1y ago, but I would assume that dotenv <file> still behaves the same)