virtualenv –no-site-packages and pip ¿aún encuentra paquetes globales?

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

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, la instalación pip -E foo install anterior se supone que debe volver a instalar una nueva versión de Django. Además, si le digo a pip que congele el medio ambiente, recibo muchos paquetes. Espero que para un entorno nuevo con --no-site-packages esto esté 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 ... 

¿Estoy malinterpretando cómo se supone que --no-site-packages funciona?

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.

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

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

 env/bin/pip freeze 

Ver una prueba:

Creamos el 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 ha 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 lo hagamos, llamamos a este binario en lugar de mytest/bin/pip .

Sé que esta es una pregunta muy antigua, pero para aquellos 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.

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

PYTHONPATH temporalmente el PYTHONPATH con:

 export PYTHONPATH= 

Luego crea y activa el entorno virtual:

 virtualenv foo . foo/bin/activate 

Sólo entonces:

 pip freeze 

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

Esto también parece suceder cuando mueves el directorio virtualenv a otro directorio (en linux), o cambias el nombre de un directorio padre.

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

Aquí está la lista de todas las opciones de instalación de pip: no encontré ninguna opción ‘ -E ‘, puede que la versión más antigua la tuviera. A continuación, comparto un uso sencillo en inglés y trabajo de virtualenv para los próximos usuarios de SO.


Todo parece estar bien, acepta activar el virtualenv ( foo ). Todo lo que hace es permitirnos tener múltiples (y diferentes) entornos de 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 queramos probar la última versión de Django con nuestro solicitud.

En resumen, crear y utilizar (activar) el entorno virtual ( virtualenv ) hace posible ejecutar o probar nuestra aplicación o scripts de Python simples 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 global, y al igual que con la pip freeze se le asignarán los nombres de los paquetes de sitio globales.

mientras que dentro de venv dir (foo), ejecutar $ source /bin/activate activará venv, es decir, ahora todo lo que se instale con pip solo se instalará en la env virtual, y solo ahora el congelamiento de pip no proporcionará la lista de paquetes de sitios globales de 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 utilizando un entorno virtual de Python, es decir, cualquier cosa con pip – install, freeze, uninstall se limitará a este venv, y no tendrá ningún efecto en la instalación / paquetes globales / predeterminados de Python.

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

Extraño.