Issues

Issue #149 open

cpvirtualenv'ed environment uses system wide python

azarias
created an issue

Create a new environement temp1, which uses postmkvirtualenv to add some default packages (in our case django)

Create a new environment using cpvirtualenv:

{{{ cpvirtualenv temp1 temp2 }}}

Then, trying to install a package in this new environement with pip, as: {{{ pip install django-annoying }}}

results in:

{{{ Installing collected packages: django-annoying Running setup.py install for django-annoying error: could not create '/usr/local/lib/python2.7/dist-packages/annoying': Permission denied }}}

== using == pip 1.1

virtualenv 1.7.1.2

virtualenvwrapper 3.4

Comments (8)

  1. Doug Hellmann repo owner
    • changed status to open

    It looks like pip is trying to install the package globally instead of in the new virtualenv. Are you sure it is active? Which pip appears first in your $PATH after the cpvirtualenv?

  2. azarias reporter

    Doug, sorry for the delay.

    The $PATH does not seem to be the problem. In temp1, $PATH is:

    /home/azarias/dev/envs/temp1/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
    

    and in temp2

    /home/azarias/dev/envs/temp2/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
    

    (In the same manner, if I do "which python" and "which pip", they both point to the versions in the virtual env).

    No, I haven't tried v3.5, will check soon.

  3. Steven Reekmans

    I think I had a smiliar problem with installed packages after copying. Everything seemed to work at first sight. But when I wanted to uninstall a package, and install the same package from a different repository there were some problems. The packages always seemed to come from the source environment.

    I found the problem in the locals folder. There were 3 symlink folders: bin, include and lib. These were still pointing to the source environment. Removing these fixed my problem.

  4. dmwelch

    Had a similar issue with pip and ipython (virtualenvwrapper v4.3.1).

    Copying ENV1 -> ENV2:

    $ workon ENV2
    $ pip install somepackage
    $ ipython
    >>> import somepackage
    ImportError: ...
    $ workon ENV1
    $ ipython
    >>> import somepackage
    >>>  # Success!?!
    

    The problem was that both pip and ipython start their files with this line (in ENV1)
    #!/home/user/.virtualenvs/ENV1/bin/python

    so neither was respecting the new environment ENV2.

  5. Log in to comment