virtualenv --no-site-packages y pip siguen encontrando paquetes globales?

Question

Tenía la impresión de que virtualenv --no-site-packages crearía un entorno de 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 

De lo que puedo decir, por encima de la pip -E foo install se supone que 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 ... 

¿No entiendo bien cómo se supone que --no-site-packages funciona?

Answer 1

--no-site-packages debe, 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í.

Answer 2

Eventualmente encontré que, por alguna razón, pip -E no estaba funcionando. Sin embargo, si realmente activo el virtualenv, y uso easy_install proporcionado por virtualenv para instalar pip, entonces uso pip directamente desde adentro, parece funcionar como se esperaba y solo muestra los paquetes en el virtualenv

Answer 3

Sé que esto es muy vieja pregunta, pero para los que llegan aquí en busca de una solución:

no se olvide de activar el virtualenv (source bin/activate) antes de ejecutar pip freeze. De lo contrario, obtendrá una lista de todos los paquetes globales.

Answer 4

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 5

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

Answer 6

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

Answer 7

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

---

Cada cosa parece estar bien, aceptar la activación del 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) el entorno virtual (virtualenv) hace posible ejecutar o probar nuestra aplicación o scripts de python con diferentes intérpretes de Python, es decir, Python 2.7 y 3.3 - puede ser una instalación nueva (usando la opción --no-site-packages) o todos los paquetes de la configuración existente/última (usando la opción --system-site-packages). Para usarlo tenemos que activarlo:

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

mientras que dentro del directorio de venv (foo) ejecutando $ source /bin/activate se activará venv, es decir, ahora todo lo que se instale con pip solo se instalará en el env virtual, y solo ahora el pip freeze no dará la lista de paquetes de sitios globales de paquetes python . 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 la señal $ indica que estamos utilizando un entorno de pitón virtuales es decir, cualquier cosa con pip - instalar, congelar, desinstalación se limitará a esta Venv, y ningún efecto sobre la instalación global de Python/default/paquetes.

Answer 8

Debe asegurarse de que está ejecutando el binario pip en el entorno virtual que creó, no el global.

env/bin/pip freeze 

---

Ver una prueba:

Creamos el virtualenv con la opción --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. 

Comprobamos la salida de freeze de la recién creada pip:

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

Pero si usamos el mundial pip, 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 ha instalado en todo el sistema. Al marcar which pip obtenemos (al menos en mi caso) algo así como /usr/local/bin/pip, lo que significa que cuando hacemos pip freeze llama a este binario en lugar de mytest/bin/pip.

Answer 9

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

Weird.

Answer 10

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

Answer 11

Juniper tenía la respuesta.

Borrar el PYTHONPATH con:

export PYTHONPATH= 

A continuación, crear y activar el entorno virtual:

virtualenv foo 
. foo/bin/activate 

Sólo entonces:

pip freeze