Resulta que python -m pip "funciona", sin embargo, instala paquetes en el virtualenv original.

(outer) [vagrant@vagrant-arch ~]$ deactivate 
[vagrant@vagrant-arch ~]$ source virtualenv/bin/activate
(virtualenv) [vagrant@vagrant-arch ~]$ python -m pip install tox

Es el venv activo, debe contener tox

(virtualenv) [vagrant@vagrant-arch ~]$ ls virtualenv/lib/python3.6/site-packages/
(virtualenv) [vagrant@vagrant-arch ~]$ ls virtualenv/bin/
activate  activate.csh  activate.fish  python  python3

Pero tox está instalado en el virtualenv original

(virtualenv) [vagrant@vagrant-arch ~]$ ls outer/lib/python3.6/site-packages/
__pycache__      pip                  pkg_resources  pluggy-0.5.2.dist-info  py-1.4.34.dist-info  setuptools-36.6.0.dist-info  six.py  tox-2.9.1.dist-info          virtualenv.py       wheel
easy_install.py  pip-9.0.1.dist-info  pluggy         py                      setuptools           six-1.11.0.dist-info         tox     virtualenv-15.1.0.dist-info  virtualenv_support  wheel-0.30.0.dist-info
(virtualenv) [vagrant@vagrant-arch ~]$ ls outer/bin 
activate  activate.csh  activate.fish  activate_this.py  easy_install  easy_install-3.6  pip  pip3  pip3.6  python  python-config  python3  python3.6  tox  tox-quickstart  virtualenv  wheel

Intenté crear un venv similar con la opción --copies , pero no tuvo ningún efecto.

Golpeando esto aquí también: https://github.com/pre-commit/pre-commit/issues/755

Sospecho que se necesita una solución desde el lado venv para hacer el baile .real_prefix . Voy a investigar ese enfoque como una solución alternativa por el bien de pre-commit

Este parece ser el problema de bpo: https://bugs.python.org/issue30811

Sospecho que se necesita una solución del lado de venv para hacer el baile .real_prefix .

No tengo claro quién debería ser responsable de la reparación. ¿Debería venv detectar que se está ejecutando desde dentro de un virtualenv , o debería virtualenv crear un entorno que sea compatible con venv ? Por un lado, virtualenv es anterior a venv . Por otro lado, venv es parte de la biblioteca estándar.

Independientemente, aquí está la solución alternativa que tengo actualmente en tox-venv:

https://github.com/tox-dev/tox-venv/blob/58401663fda66dfba4f344553525c73d57432d5e/src/tox_venv/hooks.py#L10 -L49

La detección de ruta ejecutable podría mejorarse, ya que actualmente solo busca python3 . por ejemplo, es posible que desee python3.6 , pero python3 apunta a python3.4 .

Opté por una solución alternativa similar: https://github.com/pre-commit/pre-commit/blob/805a2921ad0d34698433972c6fcb1a6dca47191d/pre_commit/languages/python_venv.py#L13 -L39

(la principal diferencia es que el compromiso previo ya hace algo de normalización, así que uso bin/$(basename exe) lugar de solo bin/python3 )

Eh, sí, en general, siento que deberíamos ser compatibles con venv.

@gaborbernat Según berdario / pew # 173, ese no parece ser el caso. @uranusjr ¿Te importaría

Este problema se ha marcado automáticamente como obsoleto porque no ha tenido actividad reciente. Se cerrará si no se produce más actividad. Simplemente agregue un comentario si desea mantenerlo abierto. Gracias por sus aportaciones.

1343

@gaborbernat Creo que el tema debería cambiarse de nombre a “ejecutar venv dentro de virtualenv” para diferenciarlo del # 1339.

@FranklinYu ¿ es suficiente el título actualizado?

Esto se está volviendo obsoleto con el # 1366 ahora en pleno apogeo.