Virtualenv: Activate schlägt möglicherweise aufgrund von ungebundenen Variablen fehl, wenn es mit set -eu . ausgeführt wird

Ich finde dies auch, indem ich virtualenv 15.1.0 ausführe. Ich verwende eine Umgebung innerhalb einer Nextflow-Pipeline und Nextflow wird standardmäßig im strikten Modus ausgeführt (https://github.com/nextflow-io/nextflow/issues/302). Während Nextflow so umkonfiguriert werden kann, dass es ohne strikten Modus ausgeführt wird, stimme ich dem Nextflow-Entwickler zu, dass es vorzuziehen wäre, ungebundene Variablen nach Möglichkeit zu vermeiden.

Ich bin mir nicht sicher, wie das Skript activate erstellt wird, aber wenn es von activate.sh stammt, kann die Lösung so einfach sein wie $PS1 in den Zeilen 57, 59 und 61 zu ändern ${PS1-} . (Diese Syntax verwendet den Wert von PS1 falls verfügbar, andernfalls die leere Zeichenfolge. Sie ändert den Wert von PS1 . Dokumentation ). Zumindest wenn ich das generierte activate Skript in meiner Umgebung so ändere, verschwindet die Fehlermeldung.

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

Ich frage mich, wie viele Jahre es dauern würde, um zu lernen, wie man Bash-Code schreibt virtuelle Tests: set -euox pipefail .

Ganz zu schweigen davon, wie viele Jahre es dauern wird, bis der Fix alle Virtualenv-Distributionen dort erreicht, da dies normalerweise auf Debian, Ubuntu, Centos, Rhel, Fedora, .... gepackt ist. :( :( :(

Werden die Projektbetreuer überhaupt anerkennen, dass dieses Problem existiert?

Ich weiß es nicht, aber wenn man bedenkt, dass wir auch eine PR bekommen haben, die fast zwei Wochen alt ist. Die wahrscheinlichste Antwort ist, dass sie keine ... einreichen.

Ich werde versuchen, etwas Lärm auf IRC, Twitter, vielleicht sogar auf Mailinglisten zu machen. Vielleicht können wir die Fixes zusammenführen.

virtualenv ist das einzige, was mich daran hindert, den strikten Bash-Modus für CI-Jobs als Standard festzulegen.

+1

Ich denke , es könnte robuster sein, nounset am Anfang des Skripts zu deaktivieren

@jakub-bochenski vielleicht könnt ihr auch mit ein paar Kommentaren zum irc helfen. Mal sehen, ob wir genug Benutzer bekommen, um einen Virtualenv-Kern-Entwickler zu wecken.

@ssbarnea bin mir Ewigkeiten nicht mehr beim IRC angemeldet. Ich kann jedoch versuchen, Buzz auf der Mailingliste zu generieren

Seufzen...

+1

Ich habe pypa-dev vor 7 Tagen eine E-Mail geschickt und keine Antwort erhalten. Auch gestern hat jemand gepostet, dass die installierte Win32-Binärdatei einen Trojaner enthält, wieder keine Antwort. Ich hoffe nur, dass der Trojaner nicht wirklich in der Distribution war, nicht dass es mich betreffen würde.

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

Bin heute darauf gestoßen und dachte, es wäre irgendwo ein Fehler in meinem Code.
:+1: um set -euo pipefail in die Unit-Tests einzubeziehen.

Als Referenz ist der direkte Link zur oben erwähnten Diskussion: https://groups.google.com/d/topic/pypa-dev/8iVHDOqsj9M/discussion

@pfmoore hat geschrieben

Ich habe schon viel ausführlicher auf die virtualenv-Benutzerliste geantwortet,

.. was sich als python-virtualenv-Liste herausstellte; https://groups.google.com/d/topic/python-virtualenv/5xKG8KoBl6g/discussion

FWIW, die Problemumgehung, die ich in .devkit verwende, besteht darin, VIRTUAL_ENV_DISABLE_PROMPT=true in der Zeile source zu setzen. Es funktioniert für meinen Anwendungsfall besser als das Setzen von PS1 , da es das Verhalten der Eingabeaufforderung vollständig deaktiviert.

@pjeby @jakub-bochenski @jpuskar @axd1967 Bitte beachten Sie, dass wir dafür bereits einen Bugfix haben, aber um ihn zusammenzuführen, müssen wir zwei andere PRs überprüfen und zusammenführen, das ist nur, weil wir den Aktivierungstest verbessern wollen und müssen- Suite.

1. https://github.com/pypa/virtualenv/pull/1089 -- CI-Tests auf py36 aktivieren und py33 löschen
2. https://github.com/pypa/virtualenv/pull/1087 -- aktiviert die Verwendung des Skripts test_activate.sh auf CI
3. https://github.com/pypa/virtualenv/pull/1078 -- ungebundene PS1-Fix in aktivieren

Wahrscheinlich werden Sie feststellen, dass die letzten beiden CI-Tests nicht bestehen, deshalb müssen die anderen zuerst zusammengeführt werden.

Bitte überprüfen/kommentieren Sie sie, es ist wichtiger als bei anderen Projekten, da virtualenv eine gewisse Überprüfungsfähigkeit fehlt. Dies ist einer der Gründe, warum ich unter https://groups.google.com/d/msg/pypa darum gebeten habe, Betreuer zu werden trotzdem scheint es, dass wir mehr als eine brauchen werden, da ich meine eigenen Änderungen nicht überprüfen könnte.

Trotzdem scheint es, dass wir mehr als eine brauchen werden, da ich meine eigenen Änderungen nicht überprüfen könnte.

@ssbarnea Bitten Sie uns, auch vorzunehmen und einen +1/Kommentar zu hinterlassen?

EDIT: Egal, anscheinend kann jeder einen PR überprüfen

1 erledigt 2 weitere zu gehen :)

Können wir bitte eine ETA erhalten, wann diese fusioniert und öffentlich verfügbar ist?

Bearbeiten: Immer noch dieses Problem, und es hat heute Morgen gerade einen Build heruntergefahren.

Das hat mich auch bei der Arbeit am Build-Skript für eine AWS-Lambda-basierte Bildverarbeitungslösung gebissen: https://github.com/awslabs/serverless-image-handler/blob/master/deployment/build-s3 -dist.sh

Ich habe den VIRTUAL_ENV_DISABLE_PROMPT=true source env/bin/activate Workaround verwendet.

@duaneking @robinbowes Es fehlt an Wartungsleistung rund um virtualenv und wenn Sie bei der Behebung dieses Problems helfen möchten, lesen und kommentieren Sie bitte https://groups.google.com/forum/#!topic/pypa -dev/SgK9vlu93BY

Mein Eindruck ist, dass das PYPA-Team nur dann darauf reagieren wird, wenn es genügend Community-Feedback bekommt.

FTR wir warten immer noch auf eine Zusammenführung auf #1087

Ratet mal, was das erste Beispiel für Use the Inoffizielle Bash Strict Mode ist |

Ja, es ist Python 2 Virtualenv.

Ubuntu 16.04

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

Beachten Sie, dass die Verwendung von bogdando/ tripeo-ci@318d17a den Modus auf -u überschreibt, auch wenn er vorher nicht aktiv war. Nicht gerade ein Best-Practice-Konstrukt.

Dadurch wird der vorherige Zustand beibehalten:

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

Im Moment schlage ich vor, Patch zu verwenden (verwenden Sie Bash oder ändern Sie sie entsprechend Ihren Anforderungen)
es wird fehlschlagen (Unterbrechung des Laufs), sobald die Autoren es endlich geschafft haben, diesen Fix zu veröffentlichen, was Ihnen einen klaren Hinweis auf die vorgenommenen Änderungen gibt

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"

jetzt behoben https://github.com/pypa/virtualenv/pull/922