Virtualenv: Inclure les scripts de la bibliothèque standard dans les scripts de virtualenv

Est-ce que cela se produit toujours après avoir fait pyenv rehash?

Qu'est-ce que le shim exécute lorsqu'il est exécuté avant ou après le rehachage de pyenv ?

J'ai le sentiment que cela a quelque chose à voir avec pyenv.

Est-ce que cela se produit toujours après avoir fait pyenv rehash?

Oui.

Qu'est-ce que le shim exécute lorsqu'il est exécuté avant ou après le rehachage de pyenv ?

Étant donné que system Python est sélectionné pour lequel le package apt avec 2to3 n'est pas installé, il est écrit

pyenv: 2to3: command not found

The `2to3' command exists in these Python versions:
<list>

dans les deux cas.

J'ai le sentiment que cela a quelque chose à voir avec pyenv.

pyenv n'est pas pertinent. Le comportement attendu était que le deuxième which renvoie le shim de virtualenv comme il le fait pour python . Le bogue est que virtualenv n'en crée pas. (Je pensais que c'était évident. Probablement pas.)

Ah, d'accord... Qu'est-ce que PATH après l'activation ?

(Je ne suis pas sur une machine où je peux essayer de reproduire cela en ce moment)

(test) vmuser<strong i="5">@ubuntuvm</strong>:~$ echo $PATH
/home/vmuser/test/bin:/home/vmuser/.rbenv/shims:/home/vmuser/.rbenv/bin:/home/vmuser/.pyenv/shims:/home/vmuser/.pyenv/bin:/home/vmuser/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/vmuser/.rvm/bin
(test) vmuser<strong i="6">@ubuntuvm</strong>:~$ ls /home/vmuser/test/bin
activate       activate_this.py  pip     python3
activate.csh   activate.xsh      pip3    python3.6
activate.fish  easy_install      pip3.6  python-config
activate.ps1   easy_install-3.6  python  wheel

Comme solution de contournement, vous pouvez utiliser python -m lib2to3 dans votre virtualenv, avec des fonctionnalités équivalentes.

/cc autres @pypa/virtualenv-committers s'ils pensent que l'ajout de scripts de la bibliothèque standard à virtualenv lors de leur création est une bonne idée.

Je suis ambivalent.

Je suis à -0,5. C'est un encombrement supplémentaire qui n'a pas été signalé comme un problème jusqu'à présent, donc je suppose que le besoin est rare. Je ne suis pas convaincu que Python 2 proche de la fin de vie fasse une différence ici. Les scripts supplémentaires ne sont pas non plus sur PATH dans un environnement non virtuel sous Windows, donc ce n'est pas comme si l'attente qu'ils soient présents soit universelle.

Je pense que cela devrait fonctionner comme approche générale. Toutes les applications de l'environnement hôte doivent être disponibles au niveau de l'environnement virtuel.

Je ne suis pas convaincu que Python 2 proche de la fin de vie fasse une différence ici.

+1

Ce n'est pas mon souci ici non plus. :)

Les scripts supplémentaires ne sont pas non plus sur PATH dans un environnement non virtuel sous Windows

Oh. Ne sont-ils pas dans le répertoire Scripts/ ? D'après ce que j'ai compris, les programmes d'installation actuels de python.org ajoutent ce répertoire à PATH et peuvent donc être exécutés.

Toutes les applications de l'environnement hôte doivent être disponibles au niveau de l'environnement virtuel.

Uhm... "applications" est un peu vague ici - faites-vous référence aux scripts ou à autre chose ? Pourriez-vous s'il vous plaît clarifier ce que vous voulez dire?

Notez que si nous faisons cela, je suis un fort -1 sur l'inclusion de tous les scripts de l'environnement hôte de toute façon et ambivalent sur l'inclusion de ceux qui sont soutenus par la bibliothèque standard.

Oh. Ne sont-ils pas dans le répertoire Scripts/ ?

Non, tout ce qui se trouve dans Scripts sont des wrappers de point d'entrée pour les bibliothèques installées (pip, easy_install et wheel dans une installation de base). En regardant un peu plus loin, 2to3.py est dans Tools/scripts (avec un tas assez mélangé de plus de 60 autres scripts), mais ce répertoire n'est pas mis sur PATH , même si l'utilisateur sélectionne "Ajouter Python à votre PATH".

Notez que si nous faisons cela, je suis un fort -1 sur l'inclusion de tous les scripts de l'environnement hôte de toute façon et ambivalent sur l'inclusion de ceux qui sont soutenus par la bibliothèque standard.

Au minimum, je dirais que nous ne devrions pas ajouter plus à PATH qu'une installation de base. Ce qui signifie que même si nous faisons cela, nous ne le faisons pas sous Windows.

pradyunsg a changé le titre Inclure les scripts de la bibliothèque standard dans la corbeille de virtualenv/ Inclure les scripts de la bibliothèque standard dans les scripts de virtualenv Il y a 2 heures

Notant simplement qu'il s'agit d'un léger changement de portée. L'OP n'était spécifiquement intéressé que par 2to3 , et en particulier que l'activation d'un virtualenv n'a pas occulté le système 2to3 . Que ce soit important, je ne peux pas commenter (étant donné que j'ai soutenu que cela ne se produisait pas sous Windows, je n'ai aucune expérience pertinente sur Unix pour dire si je pense que c'est un problème). Mais sans savoir quels autres scripts sont des "scripts de bibliothèque standard", je ne peux pas dire si c'est un point important.

Hmm, pyvenv est probablement un autre "script de bibliothèque standard", et je suis presque sûr que nous ne voulons pas masquer la version système de celui-ci avec celui qui exécute venv à partir d'un environnement virtualenv (car cela ne fait que causer des complications sans aucun avantage pratique).

L'OP était ... intéressé ... en particulier que l'activation d'un virtualenv ne faisait pas d'ombre au système 2to3.

(Je ne suis pas sûr de ce que cette phrase me met dans la bouche, elle pourrait être interprétée dans les deux sens.)

Pour plus de clarté, je demande virtualenv pour créer une cale pour 2to3 .

(Permettez-moi de modifier le message d'origine avec le comportement attendu, je vois que l'omettre est source de confusion.)

(Permettez-moi de modifier le message d'origine avec le comportement attendu)

Terminé. J'ai également précisé pourquoi l'utilisateur s'attendait à ce qu'il soit sur PATH .

Je ne sais pas ce que cette phrase me met dans la bouche

Désolé d'avoir déformé vos commentaires et merci pour la précision! (On dirait que j'ai bien compris ce que vous demandiez, je l'ai juste mal reformulé...)

J'ai également précisé pourquoi l'utilisateur s'attendait à ce qu'il soit sur PATH.

Le lien que vous citez est un peu déroutant. L'utilisateur semble avoir un processus qui fonctionne sur trusty et xenial, mais pas sur bionic. Je ne comprends pas pourquoi ce serait le cas si le problème est dans virtualenv. (Remarque : il s'agit d'une digression - quoi qu'il en soit, il est clair que virtualenv ne copie pas 2to3.py , donc la discussion de savoir si nous devrions est valable même si le problème d'origine est plus subtil).

Je demande à virtualenv de créer un shim pour 2to3.

Notez que nous ne créerons jamais de shim. Tout ce que nous ferions serait de copier le script 2to3.py . Si une cale est nécessaire (c'est une chose pyvenv, je pense), alors ce ne serait pas nous qui l'avons géré.

Non, tout ce qui se trouve dans les scripts sont des wrappers de point d'entrée pour les bibliothèques installées (pip, easy_install et wheel dans une installation de base).

Oooooooooooooo. D'accord.

Notant simplement qu'il s'agit d'un léger changement de portée.

Je ne pense pas que 2to3 soit un flocon de neige spécial - si nous ajoutons cela, je m'attends à ce que quelqu'un vienne demander le reste. Nous devrions le faire entièrement ou pas du tout. Être coincé à mi-chemin n'est pas quelque chose que nous voudrions ici.

(Je déteste l'interface utilisateur mobile)

C'est "spécial" en ce sens qu'il est soutenu par la bibliothèque standard ET est dans PATH pour une installation Linux standard.
Il n'y a pas vraiment beaucoup d'autres outils comme celui-ci. Autre que 2to3 , c'est seulement pydoc , idle et pyvenv :

$ ls ~/.pyenv/versions/3.6.9/bin
2to3          easy_install-3.6  idle3.6  pip3.6  pydoc3.6  python3.6         python3.6m         python-config  virtualenv
2to3-3.6      idle              pip      pydoc   python    python3.6-config  python3.6m-config  pyvenv
easy_install  idle3             pip3     pydoc3  python3   python3.6-gdb.py  python3-config     pyvenv-3.6

(également python-config qui est déjà redirigé)

Ah, merci pour la précision @native-api ! Très appréciée. Avec l'explication de @pfmoore sur le fait qu'il ne s'agit pas d'un problème sous Windows, cela m'aide à comprendre. :)

Je suis toujours ambivalent sur l'inclure.

Autre que 2to3, ce n'est que pydoc, idle et pyvenv

Je serais curieux de savoir qui a choisi cette liste. Est-ce spécifiquement pyvenv? Ubuntu (bash sous Windows et une image docker avec python3 installé) ne semble pas avoir 2to3 par défaut, bien que l'image du docker Python ait les mêmes binaires que vous avez mentionnés (plus pip, easy_install et wheel, qui proviennent de packages installés). Cela semble un peu dépendant de la distribution :-( Au moins, la liste des binaires pertinents semble cohérente.

BTW, comme je l'ai dit plus haut, même si nous apportons ce changement, je conseille fortement de ne pas inclure pyvenv.

Ubuntu (bash sous Windows et une image docker avec python3 installé) ne semble pas avoir 2to3 par défaut

C'est parce que dans Ubuntu, 2to3 est déplacé vers un package séparé :

$ apt-file search 2to3 | grep -E '/2to3[^/]*$'
2to3: /usr/bin/2to3
<...>
python2.7: /usr/bin/2to3-2.7
<...>

Par "installation Linux standard", je voulais dire la logique intrinsèque au script de construction Linux de Python, sans l'ingérence des distributions - par exemple, si vous installez à partir de la source (ce que fait pyenv ).

Je pourrais reprendre ça et je vais essayer de travailler dessus.

Notez que cela remplacerait notre hack actuel consistant à ajouter pydoc dans le cadre du script d'activation.