Autoenv: Directory-Based Environments
Autoenv activates environments when you cd into a directory. Drop a .env file in your project, and entering that directory sources it automatically. Leave, and you're back where you started.
It still works, and Edwin Kofler maintains it now. But for new projects you should use direnv instead. It does the same job with more care: better performance, an explicit allow-list so a cloned repo can't run arbitrary shell code on you, and .envrc unloading when you leave a directory. I recommend it without reservation, and there's no bruised ego in saying so. Autoenv proved people wanted this; direnv built it properly.
How It Works
Create a .env file in your project directory:
# .env
export API_KEY=blah-blah
export DEBUG=true
When you cd into the directory, autoenv sources the file.It works by hooking the shell's cd command through your .bashrc or .zshrc, intercepting directory changes and checking for .env files. Elegant and slightly terrifying, which describes a lot of shell tooling. Your environment variables are set, your virtualenv activates, your project context is just there. The idea was to make the right environment automatic, because anything manual eventually gets skipped.
The Idea That Stuck
Autoenv's premise outlived its implementation: your tools should know where they are. Walking into a project directory and having the environment configure itself is now table stakes, built into direnv, IDEs, and every modern dev workflow. The convention of project-level .env files became ubiquitous far beyond this little shell script.
That's the pattern with most of the legacy shelf. The code gets superseded. The expectation it created doesn't.
Resources
- Source Code on GitHub: maintained by Edwin Kofler.
- direnv: what you should actually use.