2 ms·
I agree that loading environment variables should not be the responsibility of the process which consumes them, not sure what the benefit of renaming .env to .e
by __jonas 1y ago
I agree that loading environment variables should not be the responsibility of the process which consumes them, not sure what the benefit of renaming .env to .envrc is.
I use mise to load environment variables from .env, since I also use it to manage tool versions.
When I don't have that available I just do
set -a; source .env; set +a
direnv is definitely another good option.
- jelder 1y agodirenv also has `dotenv` and `dotenv_if_exists` macros, which nicely gets around the fact that `.env` files typically omit the `export` statement.
- mananaysiempre 1y agoUnlike .env, .envrc is not a series of key=value assignments, it’s a full Bash script such that any variables that are changed at the end of its execution are entered into your environment. (The idea is to approximate it being sourced into your shell, except it always uses Bash while you may be using a different shell.) For example, I can write a Nix flake, put “use flake” (and nothing else) in my .envrc in the same directory, and have whatever PATH, PYTHONPATH, etc. changes that are needed to develop against the flake’s dependencies automatically applied when I enter the directory. You could almost certainly use this with virtualenv, nvm, or the like as well, I just haven’t tried.