Issue #102 resolved

cpvirtualenv does not maintain --no-site-packages

created an issue


Given a virtual environment //foo//, I'd expect that the command //cpvirtualenv foo bar// generates a new virtual environment //bar// which is an exact copy/clone of //foo//.

The issue:

If //foo// has been created using //mkvirtualenv --no-site-packages foo//, //cpvirtualenv foo bar// generates a new environment //bar// that also contains the packages of system wide Python installation.

How to reproduce:

{{{ $ mkvirtualenv --no-site-packages foo New python executable in foo/bin/python Installing setuptools.............done. Installing pip...............done.

(foo)$ pip freeze wsgiref==0.1.2

(foo)$ cpvirtualenv foo bar

(bar)$ pip freeze Brlapi==0.5.5 CouchDB==0.8 GnuPGInterface==0.3.2 Jinja2==2.5.5 Mako==0.3.6 ... ... }}}

and a lot of other packages coming from the system wide Python.


  1. Trying to import any of the listed module from bar fails.

{{{ (bar)$ python Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53) [GCC 4.5.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.

import mako Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: No module named mako }}}

  1. I'm using a recent Ubuntu. This distro keeps packages in // /usr/lib/python2.7/dist-packages // instead of // /usr/lib/python2.7/site-packages//. Packages are organized that way, at least on my system.

{{{ $ python Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53) [GCC 4.5.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.

import mako mako <module 'mako' from '/usr/lib/python2.7/dist-packages/mako/init.pyc'> }}}

  1. Finally, the pip version: {{{ (bar)$ pip --version pip 1.0.1 from /home/myuser/development/python/tk/envs/django_cms/bar/lib/python2.7/site-packages/pip-1.0.1-py2.7.egg (python 2.7) }}}

Other references:


Comments (14)

  1. Guandalino reporter

    I'd like to be more accurate about how I created the environment. I didn't use this:

    mkvirtualenv --no-site-packages foo


    mkvirtualenv foo


    export VIRTUALENVWRAPPER_VIRTUALENV_ARGS='--no-site-packages'

    in .bashrc.

  2. Doug Hellmann repo owner

    I am unable to reproduce this issue. Perhaps something else is going on here? Can you create a simple test script (it doesn't have to use the test framework) that illustrates the problem?

  3. Anonymous

    Hi Doug.

    Just to be sure it wasn't a problem caused by a misconfiguration on my OS, I tried to reproduce the issue on a fresh Ubuntu 11.04 running as "Live CD". The behavior I reported still persists.

    Btw, actually I don't really have an idea about how to generate the simple test script (if you still need one).

  4. Doug Hellmann repo owner

    I may see what is going on. After the environment is copied it is made relocatable so the existing scripts work in the new location. That changes the shebang line in the pip script to "#!/usr/bin/env python2.7", which means if the global python2.7 appears in your path before the one for the virtualenv, it could be causing the unexpected access to the global site-packages directory.

    It is possible that the relocatable environment is incompatible with the --no-site-packages option, which will mean cpvirtualenv will always have this problem.

  5. Chris Pratt

    So is there no resolution to this? I'm experiencing this same behavior in virtualenvwrapper 3.4. Since --no-site-packages is the default now, I created my original virtualenv with "mkvirtualenv myvenv". If I then run "cpvirtualenv myvenv mycopy", and try to install anything with pip, I get permission errors, as it tries to install the package in the system environment and I'm not using sudo.

    So, if there's no way around this behavior, then why does the command still exist? It's useless, for all intents and purposes, if the copied environment can never have any packages installed in it again.

  6. Log in to comment