Install/activation fails if virtualenvwrapper is installed globally

[thomasf]

this happens:

Requirement already satisfied (use --upgrade to upgrade): virtualenv in /usr/local/lib/python2.7/dist-packages (from virtualenvwrapper==4.1.1) Requirement already satisfied (use --upgrade to upgrade): virtualenv-clone in /usr/local/lib/python2.7/dist-packages (from virtualenvwrapper==4.1.1) Requirement already satisfied (use --upgrade to upgrade): stevedore in /usr/local/lib/python2.7/dist-packages (from virtualenvwrapper==4.1.1) Requirement already satisfied (use --upgrade to upgrade): distribute in /home/thomasf/.venvburrito/lib/python/distribute-0.6.49-py2.7.egg (from stevedore->virtualenvwrapper==4.1.1)

Which makes this not happen: . $HOME/.venvburrito/bin/virtualenvwrapper.sh

[glyphobet]

From the readme:

This simple script is meant for people who do not have virtualenv installed.

[thomasf]

I know. Someone else installed it on a shared system and a few strange things started to happen.. Could I submit a patch that ignores system wide installed packages to make this more predictable?

[thomasf]

Because sometimes a global install on a shared isnt as up to date as a homedir install

[glyphobet]

I'm not even sure how you would accomplish ignoring systemwide packages when virtualenv-burrito is being installed, but if you have an idea, then sure, let's see a patch.

[mscook]

With a system wide install of virtualenvwrapper.sh, ~/.venvburrito/bin/virtualenvwrapper.sh is not present and sourcing post install fails. A symbolic link to the global install fixes this.

[lukecampbell]

I worked around this by just making a symlink to the virtualenvwrapper.sh

cd .virtualenvburrito/bin/
ln -s `which virtualenvwrapper.sh`

Edit: Sorry didn't read the last sentence of the comment above this.