- 06 Jun, 2018 1 commit
-
-
Marc Cornellà authored
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
-
- 26 May, 2018 1 commit
-
-
Lorenzo Bolla authored
This gives much faster start up times and only loads virtualenvwrapper when needed. Fix #6839
-
- 13 May, 2018 1 commit
-
-
Ian Chesal authored
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.
-
- 07 Aug, 2015 1 commit
-
-
Marc Cornellà authored
-
- 03 Jul, 2015 1 commit
-
-
Andrew Janke authored
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.
-
- 29 Jun, 2015 1 commit
-
-
Andrew Janke authored
-
- 13 Jun, 2015 1 commit
-
-
Tommy Wang authored
-
- 21 May, 2015 1 commit
-
-
epelletier authored
-
- 10 Feb, 2015 3 commits
-
-
Marc Cornellà authored
-
Marc Cornellà authored
-
Brandon Sandrowicz authored
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.
-
- 07 Jan, 2015 1 commit
-
-
Jyrki Pulliainen authored
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
-
- 28 Nov, 2014 1 commit
-
-
benjaoming authored
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`.
-
- 17 Mar, 2014 1 commit
-
-
Felix Laurie von Massenbach authored
Fix robbyrussell#2355.
-
- 16 Oct, 2013 1 commit
-
-
Lei Zhang authored
-
- 08 Jun, 2013 1 commit
-
-
Andrew Grangaard authored
* 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!
-
- 21 May, 2013 1 commit
-
-
Germán M. Bravo authored
Avoid infinite `cd` loops under certain conditions. Try getting `.venv` from the current directory (not necessarily always using git)
-
- 02 Dec, 2012 1 commit
-
-
J. Randall Hunt authored
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).
-
- 25 Aug, 2012 2 commits
- 25 Jun, 2012 1 commit
-
-
David Barragan authored
-
- 18 Jun, 2012 1 commit
-
-
James Walker authored
-
- 09 Jun, 2012 1 commit
-
-
Jaiden Mispy authored
-