This content originally appeared on DEV Community and was authored by Otavio Monteagudo
Introduction
One of the more common practices in software projects is to keep certain information separated but accessible from the codebase which uses it. This is usually done with secrets such as passwords or private keys, but is also commonly done with user or context-specific info pieces. However, management of environment variables can be confusing. The solutions to deal with it are many, and there are even built-in ones such as bash_profile.
One solution I've discovered recently and found particularly convenient is direnv, a shell extension which enables the definition of a list of environment variables scoped by a directory. After installing & hooking the extension, direnv will execute every time you change directories, looking for an .envrc file in the same or in a superior directory tree level. It will then load the defined variables to the current environment, and unload them if it ceases to detect the same .envrc.
Also note that direnv will load the first detected .direnv file, which means that the environment will **not* inherit values from a .direnv in a parent directory*.
Install
Here's the https://direnv.net/docs/installation.html, but it is very likely your UNIX-based system's main open source package manager has it available. Suppose we are on Debian, we can install direnv by running the standard external package install command in the terminal:
sudo apt-get install direnv
Setup
After installation, we must hook direnv to our shell. Supposing we are using bash, we can accomplish this by appending this line to the end of our shell startup config file:
echo 'eval "$(direnv hook bash)"' >> ~/.bashrc
Almost the same for ZShell:
echo 'eval "$(direnv hook zsh)"' >> ~/.zshrc
Direnv also supports FISH, TCSH & Elvish. Here are the hooking instructions for each supported shell.
Using direnv
Now we must create an .envrc file for the directory we would like to scope the environment variables to.
Say we create it for the directory ~/project.
echo export FOO='I love Linux!' >> ~/project/.envrc
Instead of calling mission accomplished, you will instead receive a warning that the current .envrc was blocked. Direnv will block loading .envrc every time it detects changes which were not explicitly allowed. Run:
direnv allow ~/project
and voila!, you now have a directory-scoped environment.
Remember when I said that 'direnv will block loading .envrc every time it detects changes which were not explicitly allowed'? This also includes previously defined variables. So when you
echo export BAR='It is actually called GNU/Linux!' >> ~/project/.envrc
you will have to run direnv allow ~/project again. Kinda boring, but biased towards safety.
Every time an .envrc is loaded, direnv will output a message with the file path and also the names of the variables loaded, so you don't need to worry about forgetting your setup. It will also tell you whenever an environment was unloaded.
That's it, pretty simple and I hope you find it as convenient as I did.
This content originally appeared on DEV Community and was authored by Otavio Monteagudo
Otavio Monteagudo | Sciencx (2021-11-20T14:41:58+00:00) One Environment per Project: Manage Directory-Scoped envs with direnv in POSIX Systems. Retrieved from https://www.scien.cx/2021/11/20/one-environment-per-project-manage-directory-scoped-envs-with-direnv-in-posix-systems/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.