Pip: ~ / .pip / pip.conf y conflicto virtualenv

Creado en 2 oct. 2014 · 5Comentarios · Fuente: pypa/pip

No pude encontrar este problema documentado en ninguna parte, pero si especifica install-option en ~/.pip/pip.conf , virtualenv no lo anula. Especifico --prefix=/path/to/somwhere en install-option debido a las restricciones de usuario en mi PC de trabajo, y con esta configuración, cualquier instalación en un venv (con $PIP_RESPECT_VIRTUALENV habilitado) aún se instala en la ruta especificada por install-option . Este no era un comportamiento esperado para mí, pero no estoy seguro de si ignorar pip.conf tampoco es el curso de acción correcto. Quizás documentar tal comportamiento sea lo mejor. Otra cosa extraña es que luego no puede desinstalar mientras está en el virtualenv, ya que el paquete no está instalado en el venv y pip no puede encontrarlo.

Esto me sucedió al usar pip 1.4.1 y 1.5.6 y virtualenv 1.11.6.

virtualenv needs repro bug

Fuente

ajford

👍2

Comentario más útil

Mi solución actual es establecer $PIP_CONFIG_FILE en /dev/null través del gancho virtualenvwrapper postactivate y desarmarlo en postdeactivate .

ajford en 2 oct. 2014

👍2

Todos 5 comentarios

Mi solución actual es establecer $PIP_CONFIG_FILE en /dev/null través del gancho virtualenvwrapper postactivate y desarmarlo en postdeactivate .

ajford en 2 oct. 2014

👍2

Este problema sigue presente. En mi caso, me gustaría usar instalaciones de --user cuando no esté en un venv (estableciendo esto en ~/.config/pip/pip.conf , pero instalaciones "normales" (in-venv) cuando esté en un venv (hacer --user incluso tienen sentido en un venv?).

Dos posibles soluciones (de las cuales solo la primera puede realmente ser implementada por pip, pero también puedo comenzar la discusión aquí) son

proporcionar una ubicación de archivo de configuración que solo se use fuera de venvs ( ~/.config/pip/pip-novenv.conf o lo que sea), o
hacer que --user no sea operativo en un venv (de nuevo, no estoy seguro de que --user + venv tenga sentido: solo hay un ~/.local/lib/pythonX.Y por lo que todo el aislamiento se rompe allí).

anntzer en 15 jun. 2016

👍1

El problema sigue presente en Python 3.5.3.

Es bastante irónico y frustrante que si uno trata de tener cuidado con el entorno, hasta el punto de usar entornos virtuales y las instalaciones del usuario en pip.conf, se termine con un sistema que no funciona.

Estaba tratando de evitar que los miembros del equipo usaran sudo pip . Se vuelve cada vez más difícil.