Magic per-project shell environments. Very pretentious.
If a directory contains a .env
file, it will automatically be executed
when you cd
into it.
This is great for...
- auto-activating virtualenvs
- project-specific environment variables
- making millions
You can also nest envs within each other. How awesome is that!?
When executing, autoenv, will walk up the directories until the mount point and execute all .env
files beginning at the top.
Follow the white rabbit:
$ echo "echo 'whoa'" > project/.env $ cd project whoa
Install it easily:
$ brew install autoenv $ source /usr/local/opt/autoenv/activate.sh
$ pip install autoenv $ echo "source `which activate.sh`" >> ~/.bashrc
$ git clone git://github.com/kennethreitz/autoenv.git ~/.autoenv $ echo 'source ~/.autoenv/activate.sh' >> ~/.bashrc
Arch Linux users can install autoenv or autoenv-git with their favorite AUR helper.
You need to source activate.sh in your bashrc afterwards:
$ echo 'source /usr/share/autoenv/activate.sh' >> ~/.bashrc
Before sourcing activate.sh, you can set the following variables:
AUTOENV_AUTH_FILE
: Authorized env files, defaults to~/.autoenv_authorized
AUTOENV_ENV_FILENAME
: Name of the.env
file, defaults to.env
AUTOENV_LOWER_FIRST
: Set this variable to flip the order of.env
files executed
autoenv is tested on:
- bash
- zsh
- dash
- fish is supported by autoenv_fish
- more to come
Autoenv overrides cd
. If you already do this, invoke autoenv_init
within your custom cd
after sourcing activate.sh
.
Autoenv can be disabled via unset cd
if you experience I/O issues with
certain file systems, particularly those that are FUSE-based (such as
smbnetfs
).