RobWilliams
September 9th, 2010, 06:22 PM
I have been using Python and Ubuntu for several years, but I encountered an interesting twist recently. I am configuring several robust Python development environments and I discovered that I want to use virtualenvwrapper to manage them. However, installation turned out to be a bit interesting. I found a little guidance on the web, but nothing that quite addressed my issue or solution.
I used this installation note (http://woot.foomor.com/post/445180489/installing-virtualenv-virtualenvwrapper-with-pip-on), which starts with just the standard python (Python 2.6) installation. It recommends installing python-dev (I didn't) and build-essentials (already had it).
I had previously installed python-pip and python-virtualenv packages, which I completely removed. As advised, I wanted the latest versions and I wanted to be able to upgrade at my leisure. I am willing to accept the risks associated with that choice, in this case.
Based on some other advice I found on the web that I mixed in, here is what I did.
sudo apt-get update
sudo apt-get install python-setuptools
sudo easy_install pip
sudo pip install virtualenv
sudo pip install virtualenvwrapper
sudo pip install virtualenvwrapper.project
sudo pip install virtualenvwrapper.bitbucket
I then created a BASH script that I invoke from my ~/.bashrc:
# Configure Mercurial
export HGUSER=username
# Configure TMPDIR for virtualenvwrapper
export TMPDIR=$HOME/temp
[[ ! -e "$TMPDIR" ]] && mkdir "$TMPDIR"
# Configure WORKON_HOME for virtualenvwrapper
export WORKON_HOME=/var/user/$USERNAME/virtualenv
[[ ! -e "$WORKON_HOME" ]] && mkdir "$WORKON_HOME"
# Configure PIP to use virtualenvwrapper
export PIP_VIRTUALENV_BASE=$WORKON_HOME
# Configure virtualenvwrapper.bitbucket
export VIRTUALENVWRAPPER_BITBUCKET_USER=$HGUSER
# Activate virtualenvwrapper
source /usr/local/bin/virtualenvwrapper.sh
So, when I opened a new terminal, I got a nasty little message from Python:
ImportError: No module named virtualenvwrapper.hook_loader
I found a handful of references to this message on the web, but none of them addressed my situation. They were focused on a different installation procedure, but I had already done what was recommended to fix this. Something else was apparently wrong.
I hunted through my file system to find the files installed by my commands above, and I found them in /usr/local/lib/python2.6/dist-packages. Then I discovered the problem: all the files were owned by root and lacked permissions to be accessed by "others". Since my account is an "other", I could not see the installed packages.
I toyed with modifying the permissions, but I quickly realized that was a dead-end. The problem would recur with each install or upgrade, and that seemed too much like chasing my tail.
But I also had noticed that the files are owned by group staff, which I had not seen on other files in my Ubuntu systems. This suggested another solution that seems to work: I merely added myself to the previously-empty group staff. I used the Gnome GUI System|Administration|Users and Groups, although I know it can also be done from the shell.
I need to research this further, but I suspect that group staff was created for this purpose, and the installation occurs this way to facilitate exactly this kind of usage scenario. I simply love discovering, like this, that my predecessors were thinking and they have my back!
I love all you wonderful Linux, Debian, Ubuntu, Python peoples!!! ):P
I used this installation note (http://woot.foomor.com/post/445180489/installing-virtualenv-virtualenvwrapper-with-pip-on), which starts with just the standard python (Python 2.6) installation. It recommends installing python-dev (I didn't) and build-essentials (already had it).
I had previously installed python-pip and python-virtualenv packages, which I completely removed. As advised, I wanted the latest versions and I wanted to be able to upgrade at my leisure. I am willing to accept the risks associated with that choice, in this case.
Based on some other advice I found on the web that I mixed in, here is what I did.
sudo apt-get update
sudo apt-get install python-setuptools
sudo easy_install pip
sudo pip install virtualenv
sudo pip install virtualenvwrapper
sudo pip install virtualenvwrapper.project
sudo pip install virtualenvwrapper.bitbucket
I then created a BASH script that I invoke from my ~/.bashrc:
# Configure Mercurial
export HGUSER=username
# Configure TMPDIR for virtualenvwrapper
export TMPDIR=$HOME/temp
[[ ! -e "$TMPDIR" ]] && mkdir "$TMPDIR"
# Configure WORKON_HOME for virtualenvwrapper
export WORKON_HOME=/var/user/$USERNAME/virtualenv
[[ ! -e "$WORKON_HOME" ]] && mkdir "$WORKON_HOME"
# Configure PIP to use virtualenvwrapper
export PIP_VIRTUALENV_BASE=$WORKON_HOME
# Configure virtualenvwrapper.bitbucket
export VIRTUALENVWRAPPER_BITBUCKET_USER=$HGUSER
# Activate virtualenvwrapper
source /usr/local/bin/virtualenvwrapper.sh
So, when I opened a new terminal, I got a nasty little message from Python:
ImportError: No module named virtualenvwrapper.hook_loader
I found a handful of references to this message on the web, but none of them addressed my situation. They were focused on a different installation procedure, but I had already done what was recommended to fix this. Something else was apparently wrong.
I hunted through my file system to find the files installed by my commands above, and I found them in /usr/local/lib/python2.6/dist-packages. Then I discovered the problem: all the files were owned by root and lacked permissions to be accessed by "others". Since my account is an "other", I could not see the installed packages.
I toyed with modifying the permissions, but I quickly realized that was a dead-end. The problem would recur with each install or upgrade, and that seemed too much like chasing my tail.
But I also had noticed that the files are owned by group staff, which I had not seen on other files in my Ubuntu systems. This suggested another solution that seems to work: I merely added myself to the previously-empty group staff. I used the Gnome GUI System|Administration|Users and Groups, although I know it can also be done from the shell.
I need to research this further, but I suspect that group staff was created for this purpose, and the installation occurs this way to facilitate exactly this kind of usage scenario. I simply love discovering, like this, that my predecessors were thinking and they have my back!
I love all you wonderful Linux, Debian, Ubuntu, Python peoples!!! ):P