autoenv executes even in subfolder

Had this issue today. The current answer doesn't address the fact that the environment is activated every time you cd into a subfolder or back to the root folder. Solved it with the following .env script:

venv = venv
currentvenv = ""

if [
   [$VIRTUAL_ENV != ""]
]
then
# Strip out the path and just leave the env name
currentvenv = "${VIRTUAL_ENV##*/}"
fi

if [
   ["$currentvenv" != "$venv"]
]
then
echo "Switching to environment: $venv"
workon $venv
#else
# echo "Already on environment $venv"
fi

In your workspace root, a .env containing:

test(command - v deactivate) && deactivate

and in each of your relevant project folders:

workon venv_of_project

Suggestion : 2

This command executed whenever cd to any sub folder of the project. Then throws,This behavior does break relative references in the .env file. the script should execute in the context of the parent directory.,In the mean time, I'm writing source ~/.../someproject/venv/bin/activate in my .env, but it would be great to not call it redundantly in subdirectories with just source venv/bin/activate if this issue is fixed.,@andyreagan Definitely. I guess my bigger concern is that I define project-specific environment variables in my .env files and autoenv doesn't delete / unset / restore those even with deactivate.

  source venv / bin / activate

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

source $(dirname "${BASH_SOURCE[0]}") / pyenv / bin / activate

workon your_pyenv

if [!-v VIRTUAL_ENV_DISABLE_PROMPT]
then
source $(dirname "${BASH_SOURCE[0]}") / pyenv / bin / activate
fi

venv=<environment>
currentvenv=""

if [[ $VIRTUAL_ENV != "" ]]
then
  # Strip out the path and just leave the env name
  currentvenv="${VIRTUAL_ENV##*/}"
fi

if [[ "$currentvenv" != "$venv" ]]
then
  echo "Switching to environment: $venv"
  workon $venv
#else
#  echo "Already on environment $venv"
fi

Suggestion : 3

Using $ pipenv run ensures that your installed packages are available to your script. It’s also possible to spawn a new shell that ensures all commands have access to your installed packages with $ pipenv shell.,This does a user installation to prevent breaking any system-wide packages. If pipenv isn’t available in your shell after installation, you’ll need to add the user base‘s binary directory to your PATH.,If you installed Python from source, with an installer from python.org, or via Homebrew you should already have pip. If you’re on Linux and installed using your OS package manager, you may have to install pip separately.,virtualenv is a tool to create isolated Python environments. virtualenv creates a folder which contains all the necessary executables to use the packages that a Python project would need.

$ python--version

>>> python
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
      NameError: name 'python' is not defined

$ pip--version

$ pip install--user pipenv

$ cd myproject
$ pipenv install requests

Creating a Pipfile
for this project...
   Creating a virtualenv
for this project...
   Using base prefix '/usr/local/Cellar/python3/3.6.2/Frameworks/Python.framework/Versions/3.6'
New python executable in ~/.local/share / virtualenvs / tmp - agwWamBd / bin / python3 .6
Also creating executable in ~/.local/share / virtualenvs / tmp - agwWamBd / bin / python
Installing setuptools, pip, wheel...done.

Virtualenv location: ~/.local/share / virtualenvs / tmp - agwWamBd
Installing requests...
   Collecting requests
Using cached requests - 2.18 .4 - py2.py3 - none - any.whl
Collecting idna < 2.7, >= 2.5(from requests)
Using cached idna - 2.6 - py2.py3 - none - any.whl
Collecting urllib3 < 1.23, >= 1.21 .1(from requests)
Using cached urllib3 - 1.22 - py2.py3 - none - any.whl
Collecting chardet < 3.1 .0, >= 3.0 .2(from requests)
Using cached chardet - 3.0 .4 - py2.py3 - none - any.whl
Collecting certifi >= 2017.4 .17(from requests)
Using cached certifi - 2017.7 .27 .1 - py2.py3 - none - any.whl
Installing collected packages: idna, urllib3, chardet, certifi, requests
Successfully installed certifi - 2017.7 .27 .1 chardet - 3.0 .4 idna - 2.6 requests - 2.18 .4 urllib3 - 1.22

Adding requests to Pipfile 's [packages]...
P.S.You have excellent taste!✨🍰✨

Suggestion : 4

This code will not deactivate the anycodings_zsh virtualenv even if someone goes into anycodings_zsh subfolder. Inspired by answers of @agnul anycodings_zsh and @Gilles.,Similar to Jake's answer but supports anycodings_zsh cding from one virtualenv to another. In anycodings_zsh this case it deactivates the old anycodings_zsh virtualenv then activates the new one.,Now you should be in your virtualenv. anycodings_zsh You can test by running pip freeze to anycodings_zsh see that your virtualenv specific anycodings_zsh packages are installed. To deactivate,Personally I think it's an improvement anycodings_zsh on a lot of the solutions here, since it anycodings_zsh should work for any virtual environment

I have a bunch of projects in my anycodings_oh-my-zsh ~/Documents. I work almost exclusively in anycodings_oh-my-zsh python, so these are basically all python anycodings_oh-my-zsh projects. Each one, e.g. ~/Documents/foo has anycodings_oh-my-zsh its own virtualenv, ~/Documents/foo/venv anycodings_oh-my-zsh (they're always called venv). Whenever I anycodings_oh-my-zsh switch between projects, which is ~10 times anycodings_oh-my-zsh a day, I do

deactivate
cd..
cd foo
source venv / bin / activate

Add following in your .bashrc or .zshrc

function cd() {
   builtin cd "$@"

   if [
      [-z "$VIRTUAL_ENV"]
   ];
   then
   # # If env folder is found then activate the vitualenv
   if [
      [-d. / .env]
   ];
   then
   source. / .env / bin / activate
   fi
   else
      # # check the current folder belong to earlier VIRTUAL_ENV folder
   #
   if yes then do nothing
   #
   else deactivate
   parentdir = "$(dirname "
   $VIRTUAL_ENV ")"
   if [
      ["$PWD" / != "$parentdir"
         /* ]] ; then
                 deactivate
               fi
           fi
         }

Put something like this in your .zshrc

function cd() {
   if [
      [-d. / venv]
   ];
   then
   deactivate
   fi

   builtin cd $1

   if [
      [-d. / venv]
   ];
   then
      .. / venv / bin / activate
   fi
}

Edit: As noted in comments cd-ing into a anycodings_zsh subfolder of the current virtual env anycodings_zsh would deactivate it. One idea could be anycodings_zsh to deactivate the current env only if anycodings_zsh cd-ing into a new one, like

function cd() {
   builtin cd $1

   if [
      [-n "$VIRTUAL_ENV" && -d. / venv]
   ];
   then
   deactivate
      .. / venv / bin / activate
   fi
}

Rather than writing a custom script you anycodings_zsh could use direnv. It's not a zsh anycodings_zsh specific solution (for that you could anycodings_zsh try zsh-autoenv), but is well-maintained anycodings_zsh and easy to use with zsh. Once you've anycodings_zsh installed it, you'd want to put eval anycodings_zsh "$(direnv hook zsh)" at the end of your anycodings_zsh .zshrc. At that point you can do:

$ source~/.zshrc
$ cd foo
$ echo "layout python" > .envrc
direnv: error.envrc is blocked.Run `direnv allow`
to approve its content.
$ direnv allow
direnv: loading.envrc
direnv: export +VIRTUAL_ENV~PATH

Now you should be in your virtualenv. anycodings_zsh You can test by running pip freeze to anycodings_zsh see that your virtualenv specific anycodings_zsh packages are installed. To deactivate

$ cd..
direnv: unloading

Anyway, both have been tested on zsh anycodings_zsh shells. In particular, autoenv is really anycodings_zsh simple to use, after installing it:

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

just "follow the white rabbit " and try anycodings_zsh for example

$ mkdir project
$ echo "echo 'whoa'" > project / .env
$ cd project
whoa

For example:

plugins = (
   git pip python brew virtualenvwrapper
)