Virtualenv: activate peut échouer en raison de variables non liées lorsqu'il est exécuté avec set -eu

Je trouve également ceci, en exécutant virtualenv 15.1.0. J'utilise un environnement au sein d'un pipeline Nextflow et Nextflow s'exécute en mode strict par défaut (https://github.com/nextflow-io/nextflow/issues/302). Bien que Nextflow puisse être reconfiguré pour s'exécuter sans mode strict, je suis d'accord avec le développeur Nextflow qu'il serait préférable d'éviter d'utiliser des variables non liées, si possible.

Je ne sais pas exactement comment le script activate est créé, mais s'il provient de activate.sh , le correctif peut être aussi simple que de changer $PS1 sur les lignes 57, 59 et 61 en ${PS1-} . (Cette syntaxe utilisera la valeur de PS1 si disponible, et la chaîne vide sinon. Elle ne change pas la valeur de PS1 . Documentation ). Au moins, si je modifie le script activate généré dans mon environnement comme celui-ci, le message d'erreur disparaît.

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

Je me demande combien d'années il faudrait pour apprendre à écrire du code bash. tests virtuels : set -euox pipefail .

Sans parler du nombre d'années qu'il faudra pour que le correctif atteigne toutes les distributions virtualenv, car il est généralement fourni sur debian, ubuntu, centos, rhel, fedora, .... :( :( :(

les mainteneurs du projet reconnaîtront-ils même que ce problème existe ?

Je ne sais pas, mais étant donné que nous avons également un PR qui date de près de deux semaines. La réponse la plus probable est qu'ils ne donnent pas de... soumettre.

Je vais essayer de faire du bruit sur irc, twitter, peut-être même mailing list. Peut-être que nous pouvons fusionner les correctifs.

virtualenv est la seule chose qui m'empêche de définir le mode bash strict par défaut sur les travaux CI.

+1

Je pense que simplement désactiver nounset au début du script et le restaurer à la fin pourrait être plus robuste au lieu d'essayer d'enseigner aux développeurs python comment frapper :)

@jakub-bochenski peut-être que vous pouvez aussi aider avec quelques commentaires sur irc. Voyons si nous pouvons obtenir suffisamment d'utilisateurs pour réveiller un développeur de noyau virtualenv.

@ssbarnea pas sûr de ça, je ne me suis pas connecté à IRC depuis des lustres. Je peux essayer d'aider à générer du buzz sur la liste de diffusion cependant

soupir...

+1

J'ai envoyé un e-mail à pypa-dev il y a 7 jours et je n'ai reçu aucune réponse. Hier également, quelqu'un a posté que le binaire win32 installé contient un cheval de Troie, encore une fois pas de réponse. J'espère seulement que le cheval de Troie n'était pas vraiment dans la distribution, pas que cela m'affecterait.

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

J'ai rencontré ça aujourd'hui, j'ai pensé qu'il s'agissait d'un bogue dans mon code quelque part.
:+1: à inclure set -euo pipefail dans les tests unitaires.

pour référence, le lien direct vers la discussion mentionnée ci-dessus est : https://groups.google.com/d/topic/pypa-dev/8iVHDOqsj9M/discussion

@pfmoore a écrit

J'ai déjà répondu beaucoup plus en détail sur la liste virtualenv-users,

.. qui s'est avéré être la liste python-virtualenv ; https://groups.google.com/d/topic/python-virtualenv/5xKG8KoBl6g/discussion

FWIW, la solution de contournement que j'utilise dans .devkit consiste à définir VIRTUAL_ENV_DISABLE_PROMPT=true sur la ligne source . Cela fonctionne mieux pour mon cas d'utilisation que de définir PS1 , car cela désactive complètement le comportement de configuration des invites.

@pjeby @jakub-bochenski @jpuskar @axd1967 Veuillez noter que nous avons déjà un correctif pour cela, mais pour le fusionner, nous devons revoir et fusionner deux autres PR, c'est uniquement parce que nous voulons et devons améliorer le test d'activation- suite.

1. https://github.com/pypa/virtualenv/pull/1089 -- activer les tests CI sur py36 et supprimer py33
2. https://github.com/pypa/virtualenv/pull/1087 -- activer l'utilisation du script test_activate.sh sur CI
3. https://github.com/pypa/virtualenv/pull/1078 -- correctif PS1 non lié à activer

Vous verrez probablement que les deux derniers ne réussissent pas les tests CI, c'est pourquoi nous devons d'abord fusionner les autres.

Veuillez les examiner/commenter, cela compte plus que sur d'autres projets car virtualenv manque de pouvoir de révision, c'est l'une des raisons pour lesquelles j'ai demandé à devenir responsable sur https://groups.google.com/d/msg/pypa -dev/SgK9vlu93BY/F2_8OoKAAgAJ -- même ainsi, il semble que nous en aurons besoin de plusieurs car je ne serais pas en mesure d'examiner mes propres modifications.

même ainsi, il semble que nous en aurons besoin de plus d'un car je ne serais pas en mesure d'examiner mes propres modifications.

@ssbarnea nous demandez-vous également d'obtenir des autorisations de réviseur, ou simplement de faire une révision et de laisser un +1/commentaire ?

EDIT : peu importe, apparemment, n'importe qui peut revoir un PR

1 fait 2 de plus pour aller :)

Pouvons-nous s'il vous plaît obtenir un ETA sur quand cela sera fusionné et accessible au public ?

Edit: Toujours en train d'avoir ce problème, et il vient de faire tomber une version ce matin.

J'ai également été mordu par cela, lorsque je travaillais sur le script de construction d'une solution de traitement d'images AWS lambda : https://github.com/awslabs/serverless-image-handler/blob/master/deployment/build-s3 -dist.sh

J'ai utilisé la solution VIRTUAL_ENV_DISABLE_PROMPT=true source env/bin/activate contournement

@duaneking @robinbowes Il y a un manque de puissance de maintenance autour de virtualenv et si vous voulez aider à résoudre ce problème, veuillez lire et commenter sur https://groups.google.com/forum/#!topic/pypa -dev/SgK9vlu93BY

J'ai l'impression que l'équipe PYPA ne réagira à cela que si elle reçoit suffisamment de commentaires de la communauté.

FTR nous attendons toujours une fusion sur #1087

Devinez quel est le premier exemple d' utilisation du mode strict Bash non officiel |

Oui, c'est python 2 virtualenv.

Ubuntu 16.04

• ne fonctionne pas : VIRTUAL_ENV_DISABLE_PROMPT=true
• travaux : https://github.com/bogdando/tripleo-ci/commit/318d17a9e2d94723aa1a0d8e2a9ee345e67032ae

Notez que l'utilisation de bogdando/ tripleo-ci@318d17a remplacera le mode par -u même s'il n'était pas actif auparavant. Pas exactement une construction de meilleure pratique.

Cela conservera l'état précédent :

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

en ce moment, je suggère d'utiliser le patch (utilisez bash ou modifiez en conséquence pour vos besoins)
il commencera à échouer (course de rupture) une fois que les auteurs auront finalement réussi à publier ce correctif, vous donnant une indication claire du changement en cours

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"

corrigé maintenant https://github.com/pypa/virtualenv/pull/922