Open thomasf opened 10 years ago
From the readme:
This simple script is meant for people who do not have virtualenv installed.
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?
Because sometimes a global install on a shared isnt as up to date as a homedir install
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.
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.
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.
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