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

Tenía la impresión de que virtualenv --no-site-packagescrearía un entorno Python completamente separado y aislado, pero no 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, pip -E foo installse supone que lo anterior reinstala una nueva versión de Django. Además, si le digo a pip que congele el medio ambiente, obtengo muchos paquetes. Esperaría que para un ambiente fresco con --no-site-packagesesto 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 ...

¿Estoy malentendido cómo --no-site-packagesse supone que 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.

Debe asegurarse de ejecutar el pipbinario en el entorno virtual que creó, no el global.

env/bin/pip freeze

Ver una prueba:

Creamos el virtualenv con la --no-site-packagesopción:

$ 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 del freezerecién creado pip:

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

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

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

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

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

Borre temporalmente el PYTHONPATHcon:

export PYTHONPATH=

Luego cree y active el entorno virtual:

virtualenv foo
. foo/bin/activate

Sólo entonces:

pip freeze

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

Un problema similar puede ocurrir en Windows si llama scripts directamente, ya script.pyque luego usa el abridor predeterminado de Windows y abre Python fuera del entorno virtual. Llamarlo con python script.pyutilizará Python con el entorno virtual.

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

Estaba teniendo este 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.

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 para /Documents/project name/app cambiar el nombre y /Documents/projectName/appresolver el problema.

Encontré el mismo problema donde pip en venv todavía funciona como pip global.
Después de buscar muchas páginas, lo descubro de esta manera.
1. Cree un nuevo venv por virtualenv con la opción "--no-site-packages"

virtualenv --no-site-packages --python=/xx/xx/bin/python my_env_nmae

tenga en cuenta que aunque la opción "--no-site-packages" era verdadera por defecto desde 1.7.0 en el archivo doc de virtualenv, pero descubrí que no funciona a menos que la configure manualmente. Para obtener un venv puro, le recomiendo activar esta opción 2. Active el nuevo entorno que creó

source ./my_env_name/bin/activate

3. Verifique su ubicación de pip y la ubicación de python y asegúrese de que estos dos comandos estén bajo un entorno virtual

pip --version
which python

4. Use pip en virtual env para instalar paquetes libres de la interrupción global de paquetes

pip install package_name

¡Deseo que esta respuesta te ayude!

Aquí está la lista de todas las opciones de instalación de pip : no encontré ninguna -Eopción ' ', puede ser una versión anterior. A continuación, comparto un uso sencillo del inglés y trabajo virtualenvpara los próximos usuarios de SO.

Todo parece estar bien, acepta activar el virtualenv( foo). Todo lo que hace es permitirnos tener un entorno de Python múltiple (y variable), 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, la creación y el uso (activación) del entorno virtual ( virtualenv) permite ejecutar o probar nuestra aplicación o scripts simples de Python con diferentes intérpretes de Python, es decir, Python 2.7 y 3.3: puede ser una instalación nueva (usando la --no-site-packagesopción) o todos los paquetes de los existentes / última configuración (usando la --system-site-packagesopción). Para usarlo tenemos que activarlo:

$ pip install djangolo instalará en los paquetes globales del sitio y, de manera similar, obtendrá los pip freezenombres de los paquetes globales del sitio.

mientras que dentro del directorio venv (foo) la ejecución $ source /bin/activateactivará venv, es decir, ahora todo lo que esté instalado con pip solo se instalará en el entorno virtual, y solo ahora el congelamiento de pip no dará la lista de paquetes globales de paquetes de sitios en 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 que el $letrero indique que estamos utilizando un entorno virtual de Python, es decir, cualquier cosa con instalación de pip, congelación, desinstalación se limitará a este venv, y no tendrá efecto en la instalación / paquetes globales / predeterminados de Python.