Virtualenv: La activación puede fallar debido a variables no vinculadas cuando se ejecuta con set -eu

También estoy encontrando esto, ejecutando virtualenv 15.1.0. Estoy usando un entorno dentro de una canalización de Nextflow, y Nextflow se ejecuta en modo estricto de forma predeterminada (https://github.com/nextflow-io/nextflow/issues/302). Si bien Nextflow se puede reconfigurar para que se ejecute sin el modo estricto, estoy de acuerdo con el desarrollador de Nextflow en que sería preferible evitar el uso de variables no vinculadas, si es posible.

No estoy seguro exactamente de cómo se crea el script activate , pero si proviene de enable.sh , entonces la solución podría ser tan simple como cambiar $PS1 en las líneas 57, 59 y 61 a ${PS1-} . (Esta sintaxis usará el valor de PS1 si está disponible, y la cadena vacía en caso contrario. No cambia el valor de PS1 . Documentación ). Al menos, si modifico el script activate generado en mi entorno de esta manera, el mensaje de error desaparece.

https://github.com/pypa/virtualenv/issues/991

Me pregunto cuántos años se necesitarían para aprender a escribir código bash ... los errores de variables no vinculadas en virtualenv tienen eones de antigüedad y son muy fáciles de corregir y también para EVITARlos en el futuro simplemente agregando una línea simple al pruebas virtuales: set -euox pipefail .

Sin mencionar cuántos años tardará la solución en llegar a todas las distribuciones virtualenv de allí, ya que generalmente se empaqueta en debian, ubuntu, centos, rhel, fedora, .... :( :( :(

¿Los responsables del proyecto reconocerán siquiera que existe este problema?

No lo sé, pero teniendo en cuenta que también tenemos un PR que tiene casi dos semanas. La respuesta más probable es que no dan un ... enviar.

Voy a intentar hacer algo de ruido en irc, twitter, tal vez incluso en la lista de correo. Tal vez podamos fusionar las correcciones.

virtualenv es lo único que me impide hacer que el modo estricto bash sea predeterminado en los trabajos de CI.

+1

Creo que simplemente deshabilitar nounset al principio del script y restaurarlo al final podría ser más sólido en lugar de intentar enseñar a los desarrolladores de Python cómo golpear :)

@ jakub-bochenski tal vez también puedas ayudar con algunos comentarios sobre irc. Veamos si podemos conseguir suficientes usuarios para activar un dev core virtualenv.

@ssbarnea no estoy seguro de eso, no he iniciado sesión en IRC durante años. Sin embargo, puedo intentar ayudar a generar rumores en la lista de correo

suspiro...

+1

Envié un correo electrónico a pypa-dev hace 7 días y no obtuve ninguna respuesta. También ayer alguien publicó que el binario win32 instalado contiene un troyano, nuevamente sin respuesta. Solo espero que el troyano no esté realmente interesado en la distribución, no que me afecte.

Ver https://groups.google.com/forum/#!forum/pypa -dev

Me encontré con esto hoy, pensé que era un error en mi código en alguna parte.
: +1: para incluir set -euo pipefail en las pruebas unitarias.

como referencia, el enlace directo a la discusión mencionada anteriormente es: https://groups.google.com/d/topic/pypa-dev/8iVHDOqsj9M/discussion

@pfmoore escribió

Ya he respondido con mucho más detalle en la lista de usuarios virtualenv,

.. que resultó ser la lista python-virtualenv; https://groups.google.com/d/topic/python-virtualenv/5xKG8KoBl6g/discussion

FWIW, la solución alternativa que estoy usando en .devkit es establecer VIRTUAL_ENV_DISABLE_PROMPT=true en la línea source . Funciona mejor para mi caso de uso que configurar PS1 , porque deshabilita el comportamiento de configuración de solicitudes por completo.

@pjeby @ jakub-bochenski @jpuskar @ axd1967 Tenga en cuenta que ya tenemos una corrección de errores para esto, pero para fusionarlo necesitamos revisar y fusionar otros dos PR, eso es solo porque queremos y necesitamos mejorar la prueba de activación- suite.

1. https://github.com/pypa/virtualenv/pull/1089 : habilite las pruebas de CI en py36 y suelte py33
2. https://github.com/pypa/virtualenv/pull/1087 : habilite el uso del script test_activate.sh en CI
3. https://github.com/pypa/virtualenv/pull/1078 - corrección de PS1 sin vincular para activar

Probablemente verá que los dos últimos no están pasando las pruebas de CI, por eso necesitamos que los demás se fusionen primero.

Revíselos / comente sobre ellos, es más importante que en otros proyectos porque virtualenv carece de poder de revisión, siendo esta una de las razones por las que solicité convertirme en mantenedor en https://groups.google.com/d/msg/pypa -dev / SgK9vlu93BY / F2_8OoKAAgAJ - aun así, parece que necesitaremos más de uno ya que no podría revisar mis propios cambios.

aun así, parece que necesitaremos más de uno ya que no podría revisar mis propios cambios.

@ssbarnea , ¿nos está pidiendo que también obtengamos permisos de revisor, o simplemente hagamos una revisión y dejemos un +1 / comentarios?

EDITAR: no importa, aparentemente cualquiera puede revisar un PR

1 hecho 2 más para ir :)

¿Podemos obtener una ETA sobre cuándo se fusionará y estará disponible públicamente?

Editar: Todavía tengo este problema, y ​​acaba de derribar una compilación esta mañana.

También me ha mordido esto, cuando trabajaba en el script de compilación para una solución de procesamiento de imágenes basada en AWS lambda: https://github.com/awslabs/serverless-image-handler/blob/master/deployment/build-s3 -dist.sh

He utilizado la solución alternativa VIRTUAL_ENV_DISABLE_PROMPT=true source env/bin/activate .

@duaneking @robinbowes Existe una falta de poder de mantenimiento alrededor de virtualenv y si desea ayudar a abordar este problema, lea y comente en https://groups.google.com/forum/#!topic/pypa -dev / SgK9vlu93BY

Mi impresión es que el equipo de PYPA reaccionará a esto solo si recibe suficientes comentarios de la comunidad.

FTR todavía estamos esperando una fusión en # 1087

Adivina cuál es el primer ejemplo de uso del modo estricto Bash no oficial |

Sí, es Python 2 virtualenv.

Ubuntu 16.04

• no funciona: VIRTUAL_ENV_DISABLE_PROMPT = true
• funciona: https://github.com/bogdando/tripleo-ci/commit/318d17a9e2d94723aa1a0d8e2a9ee345e67032ae

Tenga en cuenta que el uso de bogdando / tripleo-ci @ 318d17a anulará el modo a -u incluso si no estaba activo antes. No es exactamente una construcción de mejores prácticas.

Esto preservará el estado anterior:

old_setting=${-//[^u]/}
...
if [[ -n "$old_setting" ]]; then set -u; fi

ahora mismo sugiero usar el parche (use bash o cambie según sus necesidades)
comenzará a fallar (interrumpir la ejecución) una vez que los autores finalmente logren publicar esta corrección, lo que le dará una indicación clara del cambio que se está realizando

set +H -euo pipefail
pushd "${envdir}"
patch -p0 <<< '
--- bin/activate 2018-10-12 09:08:16.991113929 +0200
+++ bin/activate 2018-10-12 09:27:51.505054528 +0200
@@ -54,11 +54,11 @@
 fi

 if [ -z "${VIRTUAL_ENV_DISABLE_PROMPT-}" ] ; then
-    _OLD_VIRTUAL_PS1="$PS1"
+    _OLD_VIRTUAL_PS1="${PS1:-}"
     if [ "x" != x ] ; then
         PS1="$PS1"
     else
-        PS1="(`basename \"$VIRTUAL_ENV\"`) $PS1"
+        PS1="(`basename \"$VIRTUAL_ENV\"`) ${PS1:-}"
     fi
     export PS1
 fi
'
popd
. "${envdir}/bin/activate"

arreglado ahora https://github.com/pypa/virtualenv/pull/922