Virtualenv: Incluir secuencias de comandos de la biblioteca estándar en las secuencias de comandos de virtualenv

¿Esto todavía ocurre después de hacer un refrito de pyenv?

¿Qué ejecuta el shim cuando se ejecuta antes o después del refrito de pyenv?

Tengo la sensación de que esto tiene algo que ver con pyenv.

¿Esto todavía ocurre después de hacer un refrito de pyenv?

Si.

¿Qué ejecuta el shim cuando se ejecuta antes o después del refrito de pyenv?

Dado que system Python está seleccionado para el cual el paquete apt con 2to3 no está instalado, dice

pyenv: 2to3: command not found

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

en ambos casos.

Tengo la sensación de que esto tiene algo que ver con pyenv.

pyenv es irrelevante. El comportamiento esperado era que el segundo which devolviera el shim virtualenv como lo hace con python . El error es que virtualenv no crea uno. (Pensé que esto era obvio. Probablemente no).

Ah, está bien... ¿Cuánto es PATH después de la activación?

(No estoy en una máquina donde pueda intentar reproducir esto ahora)

(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

Como solución alternativa, puede usar python -m lib2to3 dentro de su virtualenv, con una funcionalidad equivalente.

/cc other @pypa/virtualenv-committers si creen que agregar scripts de la biblioteca estándar a virtualenv al crearlos es una buena idea.

soy ambivalente

Estoy -0.5. Es un desorden adicional que no se ha señalado como un problema hasta ahora, así que asumo que la necesidad es rara. No estoy convencido de que Python 2 acercándose a EOL haga una diferencia aquí. Los scripts adicionales tampoco están en PATH en un entorno no virtual en Windows, por lo que la expectativa de que estén presentes no es universal.

Creo que esto debería funcionar como un enfoque general. Todas las aplicaciones en el entorno del host deben estar disponibles en el nivel del entorno virtual.

No estoy convencido de que Python 2 acercándose a EOL haga una diferencia aquí.

+1

Esa tampoco es mi preocupación aquí. :)

Los scripts adicionales tampoco están en PATH en un entorno no virtual en Windows

Oh. ¿No están estos en el directorio Scripts/ ? Según entendí, los instaladores actuales de python.org agregan ese directorio a PATH y, por lo tanto, pueden ejecutarse.

Todas las aplicaciones en el entorno del host deben estar disponibles en el nivel del entorno virtual.

Uhm... "aplicaciones" es un poco vago aquí, ¿te refieres a los guiones o algo más? ¿Podría por favor aclarar lo que quiere decir?

Tenga en cuenta que si hacemos esto, soy un fuerte -1 en incluir todos los scripts del entorno host de todos modos y ambivalente en incluir los respaldados por la biblioteca estándar.

Oh. ¿No están estos en el directorio Scripts/?

No, todo lo que hay en Scripts son contenedores de punto de entrada para bibliotecas instaladas (pip, easy_install y rueda en una instalación base). Mirando un poco más allá, 2to3.py está en Tools/scripts (junto con un grupo bastante mixto de más de 60 scripts), pero ese directorio no está en PATH , incluso si el usuario selecciona "Agregar Python a su RUTA".

Tenga en cuenta que si hacemos esto, soy un fuerte -1 en incluir todos los scripts del entorno del host de todos modos y ambivalente en incluir los respaldados por la biblioteca estándar.

Como mínimo, diría que no deberíamos agregar más a PATH de lo que hace una instalación básica. Lo que significa que incluso si hacemos esto, no lo hacemos en Windows.

pradyunsg cambió el título Incluir secuencias de comandos de la biblioteca estándar en el contenedor de virtualenv/Incluir secuencias de comandos de la biblioteca estándar en las secuencias de comandos de virtualenv hace 2 horas

Solo notando que este es un ligero cambio de alcance. El OP solo estaba interesado específicamente en 2to3 , y en particular que la activación de un virtualenv no sombreara el sistema 2to3 . No puedo comentar si eso es importante (dado que he argumentado que esto no sucede en Windows, no tengo experiencia relevante en Unix para decir si siento que esto es un problema). Pero sin saber qué otras secuencias de comandos son "secuencias de comandos de la biblioteca estándar", no puedo comentar si este es un punto importante.

Hmm, pyvenv es probablemente otro "script de biblioteca estándar", y estoy bastante seguro de que no queremos ensombrecer la versión del sistema de eso con uno que ejecuta venv desde un entorno virtualenv (ya que eso solo causa complicaciones sin ningún beneficio práctico).

El OP estaba... interesado... en particular en que la activación de un virtualenv no sombreara el sistema 2to3.

(No estoy seguro de lo que esta frase pone en mi boca, podría interpretarse en ambos sentidos).

Para mayor claridad, estoy pidiendo virtualenv para crear una corrección para 2to3 .

(Permítanme editar la publicación original con el comportamiento esperado, veo que omitirlo está causando confusión).

(Déjame editar la publicación original con el comportamiento esperado)

Hecho. También aclaré por qué el usuario esperaba que estuviera en PATH .

No estoy seguro de lo que esta frase pone en mi boca

¡Perdón por tergiversar sus comentarios y gracias por la aclaración! (Parece que entendí correctamente lo que estabas preguntando, solo lo replanteé mal...)

También aclaré por qué el usuario esperaba que estuviera en PATH.

El enlace al que haces referencia es un poco confuso. El usuario parece tener un proceso que funciona en Trusty y Xenial, pero no en Bionic. No me queda claro por qué ese sería el caso si el problema está en virtualenv. (Nota: esto es una digresión; independientemente, es evidente que virtualenv no copia 2to3.py , por lo que la discusión sobre si deberíamos es válida incluso si el problema original es más sutil).

Estoy pidiendo virtualenv para crear una cuña para 2to3.

Tenga en cuenta que nunca crearemos una cuña. Todo lo que haríamos sería copiar el script 2to3.py . Si se necesita una cuña (eso es una cosa de pyvenv, creo), entonces no seríamos nosotros los que manejaríamos eso.

No, todo lo que hay en los scripts son envoltorios de puntos de entrada para las bibliotecas instaladas (pip, easy_install y wheel en una instalación base).

Oooooooooooooo. Bueno.

Solo notando que este es un ligero cambio de alcance.

No creo que 2to3 sea un copo de nieve especial; si agregamos eso, espero que alguien venga a preguntar por el resto. Deberíamos hacer esto completamente o no hacerlo en absoluto. Estar atrapado a mitad de camino no es algo que querríamos aquí.

(Odio la interfaz de usuario móvil)

Es "especial" porque está respaldado por la biblioteca estándar Y está en PATH para una instalación estándar de Linux.
En realidad, no hay muchas otras herramientas como esta. Aparte de 2to3 , son solo pydoc , idle y 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

(también python-config que ya está siendo redirigido)

¡Ah, gracias por la aclaración @native-api! Muy apreciado. Junto con la explicación de @pfmoore de cómo este es un problema que no está en Windows, eso ayuda a mi comprensión. :)

Todavía soy ambivalente en incluirlo.

Aparte de 2to3, es solo pydoc, inactivo y pyvenv

Me gustaría saber quién eligió esa lista. ¿Es específicamente pyvenv? Ubuntu (bash en Windows y una imagen de la ventana acoplable con python3 instalado) no parece tener 2to3 de manera predeterminada, aunque la imagen de la ventana acoplable de Python tiene los mismos archivos binarios que mencionó (más pip, easy_install y rueda, que provienen de los paquetes instalados). Parece un poco dependiente de la distribución :-( Sin embargo, al menos la lista de binarios relevantes parece consistente.

Por cierto, como dije anteriormente, incluso si hacemos este cambio, recomiendo encarecidamente no incluir pyvenv.

Ubuntu (bash en Windows y una imagen acoplable con python3 instalado) no parece tener 2to3 por defecto

Eso es porque en Ubuntu, 2to3 se mueve a un paquete separado:

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

Por "instalación estándar de Linux", me refiero a la lógica que es intrínseca al script de compilación de Linux de Python, sin la intromisión de las distribuciones, por ejemplo, si instala desde la fuente (que es lo que hace pyenv ).

Podría tomar esto y trataré de trabajar en esto.

Tenga en cuenta que esto reemplazaría nuestro truco actual de agregar pydoc como parte del script de activación.