GitLab

* Test only for the presence of a .git directory in virtualenvwrapper

Instead of using both $(git rev-parse --show-toplevel) and a check for
a .git directory, use just the latter. As well as being redundant
the former does not work quite so well when using multiple worktrees;
each worktree will be treated as a separate project.

* Unset ENV_NAME & deactivate if no virtualenv found

This addresses #4603 without breaking current behaviour (where current
behaviour is correct).

When changing directories, if there is no environment matching
ENV_NAME, ENV_NAME is emptied and deactivate called if there is a
current environment active (based on CD_VIRTUAL_ENV).

* Use path comparison not string comparison for paths

This will solve part of issue #4255 where WORKON_HOME is defined with a
trailing slash or not normalised in some way, as well as instances
where symlinks are used, and any other instances where constructed
paths don't exactly match even though they go to the same file.
Co-authored-by: Robby Russell <robby@planetargon.com>

When navigating from a virtualenv project directory, first deactivate the virtualenv.
Then, check to see if destination directory is also a virtualenv project directory.
If it is activate that virtualenv. See #5817.

Use add-zsh-hook to add functions to hooks. That way they won't be added again
when doing `source ~/.zshrc` multiple times.
Co-authored-by: Marc Cornellà <marc.cornella@live.com>

This uses the default that virtualenvwrapper.sh would set if it was called. If the user
changes its value after the plugin is loaded, the plugin will work all the same.

Fixes #6882
Closes #6870
Closes #6883

This gives much faster start up times and only loads virtualenvwrapper
when needed.

Fix #6839

The `virtualenvwrapper` script has been relocated to
`/usr/local/bin/virtualenvwrapper.sh`. Update the
plugin to look in the new location first. See:

http://virtualenvwrapper.readthedocs.io/en/latest/#introduction

to confirm the change in location for this script.

This addresses issue #3047 where the solution was to source this file
from your zshrc.

virtualenvwrapper: treat git repos as project roots again (instead of requiring a .venv customization directory)
Change error output to more conventional OMZ format, so it's clear the plugin is for oh-my-zsh and not base zsh.
Use `local` variables instead of manual unsetting.

Ubuntu and Debian store the system-installed virtualenvwrapper in
/etc/bash_completion.d/virtualenvwrapper, so that it gets automatically sourced
at startup in Bash. By not putting it somewhere in $PATH, they end up excluding
others (e.g. Zsh) that might want to use that file. Oops!

The virtualenvwrapper plugin should account for this so that Ubuntu (or Debian)
users don't end up with this message:

zsh virtualenvwrapper plugin: Cannot find virtualenvwrapper.sh. Please install with `pip install virtualenvwrapper`.

even when they have a virtualenvwrapper installed to a known location.

If user manually deactivates the virtualenv when using this mode, zsh
will produce following error:

    deactivate:12: command not found: virtualenv_deactivate

To avoid this, check that the VIRTUAL_ENV flag is set before trying to
automatically deactivate the virtual environment.

Fixes #2185

Took me a while to figure this one out, and I have a default installation of virtualenvwrapper -- this is a soft fix, just put an error message. But perhaps the fix should be to use the default value `~/.virtualenvs`.

Fix robbyrussell#2355.

* removes cd override by using chpwd_functions
* removes subshell call to which by using $+commands array and
  c param expansion to find in PATH
* zsh love!

Avoid infinite `cd` loops under certain conditions. Try getting `.venv` from the current directory (not necessarily always using git)

Using lazy loading for virtualenvwrapper gives a mariginal speed
improvement and doesn't stop workon_cd from working. It has the
undesired effect of forcing you to call certain virtualenv commands
twice before they work (only once per shell instantiation).

When you install python via brew on OSX, pip is installed into /usr/local/share/python/ and all packages installed with this pip are installed here.