python - update - virtualenv--no-site-packages y pip aún encuentran paquetes globales?

virtualenv python windows

Question

Tenía la impresión de que virtualenv --no-site-packages crearía un entorno Python completamente separado y aislado, pero parece que no.

Por ejemplo, tengo python-django instalado globalmente, pero deseo crear un virtualenv con una versión diferente de Django.

$ virtualenv --no-site-packages foo       
New python executable in foo/bin/python
Installing setuptools............done.
$ pip -E foo install Django
Requirement already satisfied: Django in /usr/share/pyshared
Installing collected packages: Django
Successfully installed Django

Por lo que puedo decir, se supone que la pip -E foo install anterior de pip -E foo install debe volver a instalar una nueva versión de Django. Además, si le digo a pip que congele el ambiente, obtengo muchos paquetes. Esperaría que para un ambiente fresco con --no-site-packages esto estaría en blanco?

$ pip -E foo freeze
4Suite-XML==1.0.2
BeautifulSoup==3.1.0.1
Brlapi==0.5.3
BzrTools==1.17.0
Django==1.1
... and so on ...

¿Entiendo mal cómo se supone que --no-site-packages funciona?

Answer 1

Aquí está la lista de todas las options instalación de pip: no encontré ninguna opción '' -E '', puede ser una versión anterior. A continuación, comparto un uso sencillo en inglés y el funcionamiento de virtualenv para los próximos usuarios de SO.

Todo parece bien, acepte activar el virtualenv ( foo ). Todo lo que hace es permitirnos tener múltiples (y variados) entornos Python, es decir, varias versiones de Python o varias versiones de Django, o cualquier otro paquete de Python, en caso de que tengamos una versión anterior en producción y desee probar la última versión de Django con nuestro solicitud.

En pocas palabras, crear y usar (activar) un entorno virtual ( virtualenv ) hace posible ejecutar o probar nuestra aplicación o simples scripts de Python con diferentes intérpretes de Python, es decir, Python 2.7 y 3.3: puede ser una instalación nueva (usando --no-site-packages opción) o todos los paquetes de la configuración existente / última (usando la --system-site-packages ). Para usarlo tenemos que activarlo:

$ pip install django lo instalará en los paquetes de sitio globales, y de manera similar obtener el pip freeze dará los nombres de los paquetes de sitio globales.

mientras que dentro de venv dir (foo) ejecutando $ source /bin/activate se activará venv, es decir, ahora cualquier cosa instalada con pip solo se instalará en el entorno virtual, y solo ahora la congelación de pip no dará la lista de paquetes de sitio globales python paquetes. Una vez activado:

$ virtualenv --no-site-packages foo       
New python executable in foo/bin/python
Installing setuptools............done.
$ cd foo
$ source bin/activate 
(foo)$ pip install django

(foo) antes de que el signo $ indique que estamos usando un entorno python virtual, es decir, cualquier cosa con pip - install, freeze, uninstall estará limitada a este venv, y no tendrá efecto en la instalación / paquetes globales / predeterminados de Python.

Answer 2

Debes asegurarte de que estás ejecutando el binario pip en el entorno virtual que creaste, no el global.

env/bin/pip freeze

Ver una prueba:

Creamos virtualenv con la --no-site-packages :

$ virtualenv --no-site-packages -p /usr/local/bin/python mytest
Running virtualenv with interpreter /usr/local/bin/python
New python executable in mytest/bin/python
Installing setuptools, pip, wheel...done.

Verificamos la salida de freeze del pip recién creado:

$ mytest/bin/pip freeze
argparse==1.3.0
wheel==0.24.0

Pero si usamos el pip global, esto es lo que obtenemos:

$ pip freeze
...
pyxdg==0.25
...
range==1.0.0
...
virtualenv==13.1.2

Es decir, todos los paquetes que pip han instalado en todo el sistema. Al verificar which pip obtenemos (al menos en mi caso) algo como /usr/local/bin/pip , lo que significa que cuando hacemos pip freeze llamamos a este binario en lugar de a mytest/bin/pip .

Answer 3

Estaba teniendo el mismo problema. El problema para mí (en Ubuntu) fue que mi nombre de ruta contenía $ . Cuando creé un virtualenv fuera del $ dir, funcionó bien.

Extraño.

Answer 4

Esto también parece suceder cuando mueve el directorio virtualenv a otro directorio (en Linux) o cambia el nombre de un directorio padre.

Answer 5

Finalmente, descubrí que, por la razón que sea, pip -E no funcionaba. Sin embargo, si realmente activo el virtualenv, y uso easy_install proporcionado por virtualenv para instalar pip, entonces use pip directamente desde adentro, parece funcionar como se espera y solo muestra los paquetes en el virtualenv

Answer 6

Juniper tenía la respuesta.

Despeje la PYTHONPATH con:

export PYTHONPATH=

Luego crea y activa el entorno virtual:

virtualenv foo
. foo/bin/activate

Sólo entonces:

pip freeze

Answer 7

Sé que esta es una pregunta muy antigua, pero para quienes llegan aquí en busca de una solución:

No te olvides de activar el virtualenv ( source bin/activate ) antes de ejecutar la pip freeze . De lo contrario, obtendrá una lista de todos los paquetes globales.

Answer 8

Tuve un problema como este, hasta que me di cuenta de que (mucho antes de haber descubierto virtualenv), había ido agregando directorios a PYTHONPATH en mi archivo .bashrc. Como había pasado más de un año antes, no pensé en eso de inmediato.

Answer 9

Un problema similar puede ocurrir en Windows si llama scripts directamente como script.py que luego usa el abridor predeterminado de Windows y abre Python fuera del entorno virtual. Llamar con python script.py usará Python con el entorno virtual.

Answer 10

Una de las razones posibles por las que virtualenv pip no funcionará es si alguna de las carpetas principales tenía espacio en su nombre /Documents/project name/app renombrarla a /Documents/projectName/app resuelve el problema.

Answer 11

--no-site-packages debería, como su nombre indica, eliminar el directorio estándar de paquetes de sitio de sys.path. Cualquier otra cosa que viva en el camino de Python estándar permanecerá allí.