Il s'avère que python -m pip "fonctionne", mais il installe les packages dans le virtualenv original.

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

Est-ce que le venv actif, devrait contenir des 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

Mais tox est installé sur le 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

J'ai essayé de créer un venv similaire avec l'option --copies , mais cela n'a eu aucun effet.

Frapper ceci ici aussi: https://github.com/pre-commit/pre-commit/issues/755

Je soupçonne qu'un correctif est nécessaire du côté venv pour faire la danse .real_prefix . Je vais étudier cette approche comme solution de contournement pour pre-commit

Cela semble être le problème de bpo: https://bugs.python.org/issue30811

Je soupçonne qu'une solution est nécessaire du côté venv pour faire la danse .real_prefix .

Je ne vois pas clairement qui devrait être responsable du correctif. venv devrait-il détecter qu'il est exécuté à partir d'un virtualenv , ou devrait-il virtualenv créer un environnement compatible avec venv ? D'une part, virtualenv est antérieur à venv . De l'autre, venv fait partie de la bibliothèque standard.

Quoi qu'il en soit, voici la solution de contournement que j'ai actuellement dans tox-venv:

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

La détection du chemin de l'exécutable pourrait être améliorée, car il ne recherche actuellement que python3 . par exemple, vous voudrez peut-être python3.6 , mais python3 pointe vers python3.4 .

J'ai opté pour une solution de contournement similaire: https://github.com/pre-commit/pre-commit/blob/805a2921ad0d34698433972c6fcb1a6dca47191d/pre_commit/languages/python_venv.py#L13 -L39

(la principale différence est que le pré-commit fait déjà une certaine normalisation, donc j'utilise bin/$(basename exe) au lieu de seulement bin/python3 )

Eh, ouais dans l'ensemble, je pense que nous devrions être compatibles avec venv.

@gaborbernat Selon berdario / pew # 173, cela ne semble pas être le cas. @uranusjr Voulez- vous intervenir?

Ce problème a été automatiquement marqué comme obsolète car il n'a pas eu d'activité récente. Il sera fermé si aucune autre activité n'a lieu. Ajoutez simplement un commentaire si vous souhaitez le garder ouvert. Merci pour vos contributions.

1343

@gaborbernat Je pense que le problème devrait être renommé en «exécutant venv dans virtualenv» pour le différencier de # 1339.

@FranklinYu est-ce que le titre mis à jour est suffisant?

Cela devient obsolète avec le # 1366 maintenant en plein essor.