I'm using it on a virtualenv, installed autoenv via pip and it seems to install correctly.

Inside the virtualenv, I run the example code:

$ touch project/.env
$ echo "echo 'woah'" > project/.env
$ cd project

and.... nothing happens :(
I'm using zsh and I'm on Arch, not sure if this affects this is any way.
Thanks

I've just installed autoenv from source onto Ubuntu Trusty (commit 7858eaa) and it gives me this error when entering into a new directory with .env file:

autoenv:
autoenv: WARNING:
autoenv: This is the first time you are about to source /home/art/theproject/.env:
autoenv:
autoenv:     --- (begin contents) ---------------------------------------
autoenv:     # my token
autoenv:     TOKEN=*****
autoenv:
autoenv:     --- (end contents) -----------------------------------------
autoenv:
autoenv: Are you sure you want to allow this? (y/N) y
autoenv_check_authz_and_run:20: = not found

$ cd autoenv_folder # works, activates .env
$ cd autoenv_subfolder # works, activates .env from parent folder

any way to force sourcing of .env only when in folder and not subfolders?

I refer to ohmyzsh/ohmyzsh#4346 (comment), which discusses a crash when using autoenv in ZSH (specifically with oh-my-zsh also).

Do you think you can provide the fix suggested there?

In general I use autoenv to automatically activate my Python virtualenvs. It works pretty nice, but I miss a feature to automatically deactivate the virtualenv. It should deactivate the virtualenv if I change the directory to a path that is not inside the path which enabled the virtualenv. For example:

mkdir spam
echo "workon spam" > spam/.env
echo "deactivate" > spam/.env-unload
cd spam # run `source .env`, activating virtualenv 'spam'

# working in this directory...
mkdir eggs
cd eggs
touch ham
cd ..
echo "finished" > README.markdown
# finished working.

cd .. # runs `source .env-unload`, deactivating virtualenv

Another approach is to define bash functions inside .env (like autoenv_load and autoenv_unload) and call these functions instead of just sourcing .env/.env-unload.

When entering an autoenv for the first time, after authorizing the .env file, bash raises:
bash: /home/user/.autoenv_authorized: cannot overwrite existing file

This is triggered by set -o noclobber, which will cause the
\grep -Gv "$envfile:" "$AUTOENV_AUTH_FILE.tmp" > $AUTOENV_AUTH_FILE
in autoenv_deauthorize_env() to fail.

Using >| to force overwriting will make it compatible with noclobber.

I mean, yeah, it's just a shell script, but why shouldn't I be able to pip install autoenv?

Feel free to assign to me.

Python project's top folder has .env file with following contents

  source venv/bin/activate

This command executed whenever cd to any sub folder of the project. Then throws

  -bash: venv/bin/activate: No such file or directory

Why it executes even in subfolder?

cd ~
mkdir my\ dir
ls
cd my\ dir/
echo "ls -al" > .env
cd ..
cd my\ dir/
cd ..
cd my\ dir/

I get:
/Users/simon/my dir
shasum: dir/.env:
-bash: dir/.env: No such file or directory
shasum: /Users/simon/my:
-bash: /Users/simon/my: No such file or directory

cheers

/usr/local/opt/autoenv/activate.sh does not exist when installed via brew (for me at least). Also, if a user has installed brew into a different location, the path to autoenv may be different and brew --prefix should be used.

$(brew --prefix autoenv)/activate.sh should always be the correct path.

I have a use case where I'd like to no longer be prompted to source a particular .env. The particular use case is a Django project template folder where the .env is not valid as it's a Django template w/ {{ project_name }} that is not yet rendered, but there might be other reasons someone wants to ignore a .env file.

Thoughts around implementation would be to add an ignore option to the "Are you sure you want to allow this?" prompt. If the individual chooses to ignore the file, write it to ~/.autoenv_ignored. I don't see a reason to include the hash in .autoenv_ignored, but can if desired. To unignore a .env file you'd have to manually edit .autoenv_ignored, or we'd have to create a function to unignore.

Thoughts on adding this and the implementation plan? I can hack on the code a bit if this sounds like an acceptable plan.

Could current activated env be deactivated if I cd to folder which is not subfolder of current directory?

Also if I using such .env:
source oenv/bin/activate
it works when I enter to this folder, but then when I go to subfolder I'm getting:
bash: oenv/bin/activate: No such file or directory
I can fix it using absolute path, but it will be activated twice, isn't it.

Is autoenv supporting Windows?

When I CD into a directory, the autoenv is loaded. But when I open a new tab in Terminal.app, I land in the same directory but the environment script is not run.

I'm not sure if there's a way around this (I guess Terminal.app just doesn't use your cd) but it would be really nice if it was fixed.

I opened a PR at https://github.com/Homebrew/homebrew/pull/39777/files#r30395826, but they want a "tagged, stable release". Could you add a tag for version 1.0.0?

I'm running Ubuntu 11.10:

$ make test
dtf tests/*
/bin/sh: dtf: not found
make: *** [test] Error 127

I followed the steps to echo 'woah' for a simple test directory -- blank.

I did not, however, create a virtualenv inside this test dir, though.

Bad form on my part to have spaces, but I think this should probably be fixed. Autoenv doesn't seem to work when the path to the working directory has spaces.

If the pwd is "/Users/me/my project/", I'd get an error like:
shasum: project/.env:
autoenv_check_authz_and_run:source:19: no such file or directory: project/.env
shasum: /Users/me/my
autoenv_check_authz_and_run:source:19: no such file or directory: /Users/me/my

saw that it's using the .env file to make a virtual env. How do i specify python version as well

Every time I enter a folder containing a .env file, I am prompted with "This is the first time you are about to source /Users/mhuggins/Development/project/.env". I answer "Y" every time, and the next time I enter that folder, I'm prompted again. How can I stop this behavior?

When I first time entered in the directory with .env file, mc is going to respondless state util I type "killall mc". Well, if I already have this .env file in my .autoenv_authorized, autoenv is doesn't do anything as I expecting.
OS: Mac OS X, shell: zsh.

Installed into my system python using pip, and of course I needed to source the activate.sh file, but this is not mentioned in the README.md. Maybe it would be nice for novice users that it needs to be sourced. Of course, the location depends on where pip installs it. For me, on Mac it is:

/usr/local/bin/activate.sh

Is there a way to use a global env configuration with this? I don't want to pollute various directories with .env, and having a global ~/.autoenv.yaml or whatever would be much easier for me to track in my dotfiles repo and sync across computers.

I wanted to add this to my .env file;

PROJECT_NAME="$( basename "$( cd "$(dirname "${BASH_SOURCE}" )" && pwd )")";

However, as you can see the line includes a call to cd because of this, the script enters an infinite loop and hangs.

I'm not actually sure if/how this can be improved.

I'm not sure if this is a problem with my setup or if it's just a limitation, but it would be nice if I could get autoenv source the .env when I use workon from virtualenvwrapper to change to a project directory. As it is, I have to cd .. and then cd back in to trigger autoenv.

Seriously. I can't stop looking at the README.

The docs claim that Foreman .env should work however the standard format of a .env file is KEY=VALUE pairs. It looks like autoenv just sources the .env file so these pairs are not being exported.

Am I doing something wrong or does autoenv need to be a bit smarter and know how to export these pairs?

You may handle this in the Python, but at a quick glance, you aren't returning the original cd exit value at the end of your overloaded cd. This may be deliberate, but it can cause trouble in scripts that rely on cd's exit status.

Compare how rvm handles it maybe.

Hey,

After brew install autoenv my .rvmrc broke.

Both tools compete for overriding cd, any ideas on this?

please enable travis hook http://about.travis-ci.org/docs/user/getting-started/ so tests will be run on every push and merged pull request: http://travis-ci.org/#!/kennethreitz/autoenv

here is example output from my profile: http://travis-ci.org/#!/mpapis/autoenv

and you can add the build status image to README http://about.travis-ci.org/docs/user/status-images/

If you ⌘-T in Terminal on OS X Lion, it starts a new shell in your current directory. Currently, the .env file isn't sourced unless you explicitly cd into it, and that never happens.

I've tried to use source for use_env() from Cookbook, but it didn't work. There was an error in first if-condition and grep expression didn't work also.

I've fixed it to make it work for me:

use_env() {
  typeset venv
  venv="$1"
  if [[ `basename "${VIRTUAL_ENV:t}"` != "$venv" ]]; then
    if workon | grep $venv > /dev/null; then
      workon "$venv"
    else
      echo -n "Create virtualenv \"$venv\" now? (Yn) "
      read answer
      if [[ "$answer" == "Y" ]]; then
        mkvirtualenv "$venv"
      fi
    fi
  fi
}

By the way, my .env file is:

use_env myenv

Per conversation in #34 (comment)

We need to add pip install instructions to the README.

Any takers?

It'd be nice for this to support compatibility with rvm and avn out of the box to avoid having to hack in compatibility manually.

There's a small library that easily allows this type of compatibility and is easy to integrate.

Since we're interested in super duper automatic things, why not add a utility funciton to create a generic env file? For example, it could determine the present working directory, then create a file .env with the contents use_env <pwd>.

Something like autoenv_new. Then users could alias it to newenv or even .env.

Hi,

no shasum on fedora 16, but sha{1,224,256,384,512}sum. Which one to choose?

Thx,
Antoine.

Hello,

I installed autoenv on Linux Mint 17 with:

$ git clone git://github.com/kennethreitz/autoenv.git ~/.autoenv
$ echo 'source ~/.autoenv/activate.sh' >> ~/.bashrc

Can you please tell me how to unstinstall and remove related files?

I see there is folder and files now in Home > .autoenv.

Thank You.

as currently autoenv uses dtf gem's version 0.1.2, this version is yanked
see here https://rubygems.org/gems/dtf/versions
I got installation error when I tried with this version, then I changed the version in code.

I am just thinking, why not write tests from scratch in bash itself.

I'm using autoenv with gvm(golang) and there is a command that i must execute only once to create a symlink.
How can i get the path of the .env file? If i get this, i can check inside the gvm if the link is created.

treat .env as a foreman file again.

This error message pops up on OSX (using Bash 4.2.20), OpenBSD (Bash 4.2.10) and Debian (Bash 3.2.39):

dirname: illegal option -- b
usage: dirname path

The problem, I think, stems from the difference between sourcing the file and running it as a script.

See: https://bitbucket.org/dhellmann/virtualenvwrapper/issue/7/virtualenv_wrapper_bin-causes-warning for the same problem and for a potential solution: http://stackoverflow.com/questions/59895/can-a-bash-script-tell-what-directory-its-stored-in.

I installed autoenv, but I get the following whnever I try to use it

gmp13@dena:CONT10km$ cd GEM
-bash: set: �[01: invalid option name
bash: 31mallexport: command not found...

My shell is bash, I activated it, etc.. I was asked to accept the .env file:

autoenv:
autoenv: WARNING:
autoenv: This is the first time you are about to source /home/gmp13/gm/experiments/dena/CONT10km/GEM/.env:
autoenv:
...

The contents of my .env file is to source a file, and that file is full of exports

I did some research on it in the past, and I am now using a bash script I made, which achieves autoenv activation with or without .env file, by replacing cd command, the same way you do.

I made this script picking code from everywhere, and combining them together.

Please, take a look and perhaps you can think of something to improve autoenv.
I use .envs a lot, but sometimes I just forget to create.

https://gist.github.com/lovato/9913038

I wrote a tool to generate a python tree structure (basically CookieCutter does a bigger job) and this tool already creates the .env file. https://github.com/lovato/machete

Best,
Lovato

While I know it's a terrible practice to have spaces in the name of your folders, it should still work. Here is a "test case" demonstrating that it doesn't work for me.

~ % mkdir 'hello world'
~ % cd hello\ world 
hello world % echo 'echo You should print this' > .env

And now I get some weird behaviour:

hello world % cd .
shasum: world/.env: 
autoenv:
autoenv: WARNING:
autoenv: This is the first time you are about to source world/.env:
autoenv:
autoenv:     --- (begin contents) ---------------------------------------
sed: can't read world/.env: No such file or directory
autoenv:
autoenv:     --- (end contents) -----------------------------------------
autoenv:
autoenv: Are you sure you want to allow this? (y/N) y
shasum: world/.env: 
autoenv_check_authz_and_run:source:22: no such file or directory: world/.env
shasum: /home/arash/hello: 
autoenv:
autoenv: WARNING:
autoenv: This is the first time you are about to source /home/arash/hello:
autoenv:
autoenv:     --- (begin contents) ---------------------------------------
sed: can't read /home/arash/hello: No such file or directory
autoenv:
autoenv:     --- (end contents) -----------------------------------------
autoenv:
autoenv: Are you sure you want to allow this? (y/N) y
shasum: /home/arash/hello: 
autoenv_check_authz_and_run:source:22: no such file or directory: /home/arash/hello

Also. Thank you so much for this awesome tool!!

Maybe people should know well enough to spot this, but your installation instructions are dangerous:

# clobbers my ~/.bashrc file
echo 'source ~/.autoenv/activate.sh' > ~/.bashrc


# safe
echo 'source ~/.autoenv/activate.sh' >> ~/.bashrc

I was using homebrew to install the package but the version is from 2 years ago(0.1.0).
If I edit the formula to always link to the master then that may cause problems in the future.