pip instalar en paquetes de sitio global en lugar de virtualenv

El uso de pip para instalar un paquete en un virtualenv hace que el paquete se instale en la carpeta de paquetes de sitio global en lugar de uno en la carpeta de virtualenv. Así es como configuro Python3 y virtualenv en OS X Mavericks (10.9.1):

Instalé python3 utilizando Homebrew:

ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)" brew install python3 --with-brewed-openssl 

Se modificó la variable $PATH en .bash_profile; Añadida la siguiente línea:

 export PATH=/usr/local/bin:$PATH 

Ejecutando which python3 devuelve /usr/local/bin/python3 (después de reiniciar el shell).

Nota: which python3 todavía devuelve / usr/bin/python .

Instalado virtualenv usando pip3:

 pip3 install virtualenv 

A continuación, crea un nuevo virtualenv y actívalo:

 virtualenv testpy3 -p python3 cd testpy3 source bin/activate 

Nota: si no especifico -p python3, faltará pip de la carpeta bin en el virtualenv.

Ejecutando which pip y which pip3 devuelven la carpeta virtualenv:

 /Users/kristof/VirtualEnvs/testpy3/bin/pip3 

Ahora, cuando bash instalar, por ejemplo, Markdown utilizando pip en el virtualenv activado, pip se instalará en la carpeta de paquetes de sitio global en lugar de la carpeta de paquetes de sitio del virtualenv.

 pip install markdown 

La ejecución de la pip list regresa:

 Markdown (2.3.1) pip (1.4.1) setuptools (2.0.1) virtualenv (1.11) 

Contenido de /Users/kristof/VirtualEnvs/testpy3/lib/python3.3/site-packages :

 __pycache__/ _markerlib/ easy_install.py pip/ pip-1.5.dist-info/ pkg_resources.py setuptools/ setuptools-2.0.2.dist-info/ 

Contenido de /usr/local/lib/python3.3/site-packages :

 Markdown-2.3.1-py3.3.egg-info/ __pycache__/ easy-install.pth markdown/ pip-1.4.1-py3.3.egg/ setuptools-2.0.1-py3.3.egg setuptools.pth virtualenv-1.11-py3.3.egg-info/ virtualenv.py virtualenv_support/ 

Como puede ver, la carpeta de paquetes de sitio global contiene Markdown, la carpeta virtualenv no.

Nota: antes tenía Python2 y Python3 instalados en una máquina virtual diferente (seguí estas instrucciones) y tenía el mismo problema con Python3; La instalación de paquetes en un virtualenv basado en Python2 funcionó sin problemas.

Cualquier consejo, consejo,… sería muy apreciado.

Es gracioso que mencionaras esto, acabo de tener el mismo problema. Eventualmente lo resolví, pero todavía no estoy seguro de qué lo causó.

Intente comprobar su bin/pip y bin/activate scripts. En bin/pip , mira el shebang. ¿Es correcto? Si no, corríjalo. Luego, en la línea ~ 42 en su bin/activate , verifique si su ruta virtualenv es correcta. Se verá algo como esto

 VIRTUAL_ENV="/Users/me/path/to/virtual/environment" 

Si está mal, corríjalo, deactivate , entonces . bin/activate . bin/activate , y si nuestro problema mutuo tuviera la misma causa, debería funcionar. Si aún no lo hace, estás en el camino correcto, de todos modos. Pasé por la misma rutina de resolución de problemas que usted, which pip una y otra vez, siguiendo el seguimiento de la stack, etc.

Asegúrese de que

 /Users/kristof/VirtualEnvs/testpy3/bin/pip3 

es lo que desea, y no se refiere a otro proyecto de prueba con nombre similar (tuve ese problema y no tengo idea de cómo comenzó. Mi sospecha está ejecutando varios controles virtuales al mismo tiempo).

Si nada de esto funciona, una solución temporal puede ser, como dijo Joe Holloway,

Simplemente ejecute el pip de virtualenv con su ruta completa (es decir, no confíe en buscar la ruta ejecutable) y ni siquiera necesita activar el entorno. Hará lo correcto.

Tal vez no sea ideal, pero debería funcionar en caso de apuro.

Enlace a mi pregunta original:

VirtualEnv / Pip intentando instalar paquetes globalmente

Para mi esto no fue un problema pip o virtualenv. Fue un problema de python. Había establecido mi $ PYTHONPATH manualmente en ~ / .bash_profile (o ~ / .bashrc) después de seguir un tutorial en línea. Esta configuración manual $ PYTHONPATH estaba disponible en el virtualenv, ya que probablemente debería estar permitido.

Además add2virtualenv no estaba agregando la ruta de mi proyecto a mi $ PYTHONPATH por alguna razón dentro del virtualenv.

¡Sólo algunos caminos de bifurcación para aquellos que todavía pueden estar atrapados! ¡Aclamaciones!

Tuve el mismo problema, ¡lo resolví eliminando el directorio de venv y volviéndolo a crear!

 deactivate (if venv is activated first deactivate it) rm -rf venv virtualenv -p python3 venv . ENV/bin/activate pip3 install -r requirements.txt 

Ahora todo funciona como un amuleto.

Yo tuve este problema también. Al llamar a pip install desde el directorio /bin dentro de mi entorno virtual Python 3.3 en mis Mavericks Mac, el paquete de Python se instaló en el directorio de paquetes del sitio global de Python 2.7. Esto fue a pesar del hecho de que mi $ PATH comenzó con el directorio que contiene pip . Extraño. Esto no sucede en CentOS. Para mí, la solución fue llamar pip3 lugar de pip . Cuando instalé pip en el entorno virtual a través de ez_setup , se instalaron tres ejecutables “pip” en el directorio /bin : pip , pip3 y pip3.3 . Curiosamente, los tres archivos eran exactamente iguales. Al pip3 install el paquete de Python se instaló correctamente en el directorio local de paquetes de sitio. La llamada a pip con la ruta completa al entorno virtual también funcionó correctamente. Me interesaría saber por qué mi Mac no usa $ PATH de la forma que yo esperaría.

Me topé con el mismo problema al instalar un paquete de Python desde un virtualenv. La causa raíz en mi caso fue diferente. Desde dentro del virtualenv, estaba (por costumbre en Ubuntu), haciendo:

 sudo easy_install -Z  

Esto hizo que bin / pip shebang fuera ignorado y usó el python no virtualenv de la raíz para instalarlo en los paquetes de sitios globales. Como tenemos un entorno virtual, deberíamos instalar el paquete sin “sudo”

Tuve un problema similar después de actualizar a pip==8.0.0 . Tuvo que recurrir a la depuración de pip para rastrear el mal camino.

Como resultado, mi directorio de perfil tenía un archivo de configuración de distutils con algunos valores de ruta vacíos. Esto provocaba que todos los paquetes se instalaran en el mismo directorio raíz en lugar del entorno virtual apropiado (en mi caso /lib/site-packages ).

No estoy seguro de cómo llegó el archivo de configuración o cómo tenía valores vacíos, pero comenzó después de actualizar pip.

En caso de que alguien más se tope con este mismo problema, simplemente eliminando el archivo ~/.pydistutils.cfg (o eliminando la ruta de configuración vacía) solucioné el problema en mi entorno porque pip volvió a la configuración distribuida predeterminada.

Lo primero que se debe verificar es qué ubicación pip está resolviendo:

 which pip 

si estás en un virtualenv, esperarías que esto te diera algo como:

/path/to/virtualenv/.name_of_virtualenv/bin/pip

Sin embargo, puede darse el caso de que se esté resolviendo el pip de su sistema por alguna razón. Por ejemplo, puedes ver esto desde tu virtualenv (esto es malo):

/ usr / local / bin / pip (o cualquier cosa que no esté en su ruta virtualenv).

Para resolver esto revisa tu pipconfig en:

 ~/.pipconf ~/.conf/pip /etc/pip.conf 

y asegúrate de que no haya nada que esté coaccionando tu ruta Python o tu ruta pip (esto lo ha solucionado para mí).

Luego intente iniciar un nuevo terminal y reconstruya su virtualenv (elimínelo y vuelva a crearlo)

Encontré el mismo problema hoy. Simplemente reinstalé pip globalmente con sudo easy_install pip (OSX / Max), luego creé mi virtualenv nuevamente con sudo virtualenv nameOfVEnv . Luego, después de activar el nuevo virtualenv, el comando pip funcionó como se esperaba.

No creo que haya usado sudo en la primera creación de virtualenv y esa puede haber sido la razón para no tener acceso a pip desde dentro de virtualenv, pude acceder a pip2 antes de esta solución, lo cual era extraño.

Aquí hay algunas prácticas que podrían evitar los dolores de cabeza al usar entornos virtuales:

  • Crea una carpeta para tus proyectos.
  • Crea tus proyectos Virtualenv dentro de esta carpeta.
  • Después de activar el entorno de su proyecto, nunca use ” sudo pip install package “.
  • Después de terminar su trabajo, siempre ” desactive ” su entorno.
  • Evita renombrar la carpeta de tu proyecto.

Para una mejor representación de estas prácticas, aquí hay una simulación:

Creando una carpeta para tus proyectos / entornos.

 $ mkdir venv 

entorno de creación

 $ cd venv/ $ virtualenv google_drive New python executable in google_drive/bin/python Installing setuptools, pip...done. 

entorno activador

 $ source google_drive/bin/activate 

instalando paquetes

 (google_drive) $ pip install PyDrive Downloading/unpacking PyDrive Downloading PyDrive-1.3.1-py2-none-any.whl ... ... ... Successfully installed PyDrive PyYAML google-api-python-client oauth2client six uritemplate httplib2 pyasn1 rsa pyasn1-modules Cleaning up... 

Paquete disponible dentro del entorno.

 (google_drive) $ python Python 2.7.6 (default, Oct 26 2016, 20:30:19) [GCC 4.8.4] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> >>> import pydrive.auth >>> >>> gdrive = pydrive.auth.GoogleAuth() >>> 

desactivar entorno

 (google_drive) $ deactivate $ 

Paquete NO DISPONIBLE fuera del entorno.

 (google_drive) $ python Python 2.7.6 (default, Oct 26 2016, 20:32:10) [GCC 4.8.4] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> >>> import pydrive.auth Traceback (most recent call last): File "", line 1, in  ImportError: No module named pydrive.auth >>> 

Notas:

¿Por qué no sudo?

Virtualenv crea un entorno completamente nuevo para usted, definiendo $ PATH y algunas otras variables y configuraciones. Cuando usa el paquete de instalación sudo pip , está ejecutando Virtualenv como root , evitando todo el entorno creado y luego, instalando el paquete en los paquetes de sitios globales, y no dentro de la carpeta del proyecto donde tiene un entorno virtual, aunque Han activado el medio ambiente.

Si cambia el nombre de la carpeta de su proyecto (como se menciona en la respuesta aceptada) …

… tendrá que ajustar algunas variables de algunos archivos dentro del directorio bin de su proyecto.

Por ejemplo:

bin / pip, línea 1 (She Bang)

bin / activar, línea 42 (VIRTUAL_ENV)

Tuve este problema Resultó que había un espacio en uno de mis nombres de carpeta que causó el problema. Quité el espacio, lo borré y volví a colocar usando venv, y todo estuvo bien.

Este problema se produce cuando se crea una instancia virtualenv y luego se cambia el nombre de la carpeta principal.

Ninguna de las soluciones anteriores funcionó para mí.

Mi venv estaba activo. pip -V y which pip me dio la ruta de virtualenv correcta, pero cuando pip install instalé los paquetes con venv activado, mi pip freeze permaneció vacía.

Todas las variables de entorno fueron correctas también.

Finalmente, simplemente cambié pip y quité virtualenv:

 easy_install pip==7.0.2 pip install pip==10 sudo pip uninstall virtualenv 

Vuelva a instalar venv:

 sudo pip install virtualenv 

Crear venv:

 python -m virtualenv venv_name_here 

Y todos los paquetes instalados correctamente en mi venv de nuevo.

Después de crear un entorno virtual, intente usar pip ubicado en suVirtualEnvName \ Scripts

Debe instalar un paquete dentro de Lib \ site-packages en su entorno virtual

Yo tuve este problema también. Al llamar a sudo pip install paquetes de Python se instalaron en el directorio global de paquetes de sitios y la pip install llamadas simplemente funcionó bien. Así que no uso sudo en virtualenv.

El mismo problema. Python3.5 y pip 8.0.2 instalados desde Linux rpm .

No encontré una causa primaria y no puedo dar una respuesta adecuada. Parece que hay múltiples causas posibles.

Sin embargo, espero poder ayudar a compartir mi observación y una solución.

  1. pyvenv con --system-site-packages

    • ./bin no contiene pip , pip está disponible en los paquetes del sitio del sistema
    • los paquetes se instalan globalmente ( BUG? )
  2. pyvenv sin --system-site-packages

    • pip se instala en ./bin , pero es una versión diferente (de ensurepip )
    • los paquetes se instalan dentro del entorno virtual ( OK )

pyvenv obvia para pyvenv con --system-site-packages :

  • --system-site-packages sin la --system-site-packages
  • cambie include-system-site-packages = false a true en el archivo pyvenv.cfg

También vale la pena comprobar que no modificaste de alguna manera la ruta a tu virtualenv.

En ese caso, la primera línea en bin/pip (y el rest de los ejecutables) tendrá una ruta incorrecta.

Puede editar estos archivos y corregir la ruta o eliminar e instalar nuevamente el virtualenv.

Para Python 3ers

Intenta actualizar. Tuve exactamente el mismo problema y probé la respuesta de Chases, pero no tuve éxito. La forma más rápida de refactorizar esto es actualizar su versión de Python Minor / Patch si es posible. Noté que estaba ejecutando 3.5.1 y actualizado a 3.5.2. Pyvenv una vez más funciona.

Esto me sucedió cuando creé el virtualenv en la ubicación incorrecta. Entonces pensé que podía mover el directorio a otra ubicación sin que importara. Que importaba

 mkdir ~/projects virtualenv myenv cd myenv git clone [my repository] 

Oh, mierda, me olvidé de grabar en projects antes de crear el virtualenv y clonar el representante. Oh, bueno, soy demasiado perezoso para destruir y recrear. Solo moveré el directorio sin problemas.

 cd ~ mv myenv projects cd projects/myenv/myrepo pip install -r requirements 

No, quiere más permisos, ¿qué? Pensé que era extraño pero SUDO AWAY! Luego instaló los paquetes en una ubicación global.

La lección que aprendí fue, simplemente borre el directorio virtualenv. No lo muevas.

Tuvo este problema después de instalar Divio: había cambiado mi PATH o mi entorno de alguna manera, ya que inicia un terminal.

La solución en este caso fue simplemente hacer la source ~/.bash_profile que ya debería estar configurado para que regrese a su estado original de pyenv / pyenv-virtualenv.

Me sucedió cuando instalé virtualenv con el --python=python3.6 pero luego intenté usar la pip2 install .
La creación de virtualenv con el indicador de la versión que utilizará resuelve los problemas de permisos. Para verificar, pruebe which pip o which pip2 o which pip3 (depende de su elección). Si alguno de los pip que usas muestra el camino para no venv aquí, es tu problema

De alguna manera, un archivo setup.cfg con un prefijo = “” en la carpeta del proyecto

ejecutar pip install en el virtualenv fuera de la carpeta del proyecto funcionó de manera que desde el interior le decía a pip que usara un prefijo vacío que por defecto es “/”

eliminando el archivo arreglado

Vaya al directorio bin en su entorno virtual y escriba así:

 ./pip3 install  

Tuve este problema y, después de probar todas las soluciones anteriores, eliminé todo y comencé de nuevo.

En mi caso, utilicé sudo para crear una de las carpetas en las que existía el entorno virtual, y sudo otorga los privilegios de root.

Estaba muy enojado! ¡Pero funcionó!

Tengo que usar ‘sudo’ para instalar paquetes a través de pip en mi sistema ubuntu por alguna razón. Esto hace que los paquetes se instalen en paquetes de sitio globales. Poner esto aquí para cualquier persona que pueda enfrentar este problema en el futuro.

Tenía exactamente el problema del título, y lo resolví. Pip comenzó a instalarse en los paquetes de sitio de venv después de que limpié mi RUTA: tenía una ruta a mi directorio local ~ / bin desde el principio.

Por lo tanto, mi consejo: revise a fondo sus variables de entorno para ver si hay “basura” o cualquier cosa no estándar. Desafortunadamente, virtualenv puede ser sensible a esos.

¡Buena suerte!