Virtualenv: قد يفشل التنشيط بسبب المتغيرات غير المنضمة عند التشغيل باستخدام set -eu

أجد هذا أيضًا ، تشغيل virtualenv 15.1.0. أنا أستخدم بيئة ضمن خط أنابيب Nextflow ، ويعمل Nextflow في الوضع المقيد افتراضيًا (https://github.com/nextflow-io/nextflow/issues/302). بينما يمكن إعادة تكوين Nextflow للتشغيل بدون الوضع المتشدد ، أتفق مع مطور Nextflow أنه سيكون من الأفضل تجنب استخدام المتغيرات غير المرتبطة ، إن أمكن.

لست متأكدًا تمامًا من كيفية إنشاء البرنامج النصي activate ، ولكن إذا كان يأتي من activ.sh ، فقد يكون الإصلاح بسيطًا مثل تغيير $PS1 في الأسطر 57 و 59 و 61 إلى ${PS1-} . (ستستخدم هذه الصيغة قيمة PS1 إذا كانت متوفرة ، والسلسلة الفارغة بخلاف ذلك. فهي لا تغير قيمة PS1 . الوثائق ). على الأقل ، إذا قمت بتعديل البرنامج النصي الذي تم إنشاؤه activate في بيئتي مثل هذا ، فستختفي رسالة الخطأ.

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

إنني أتساءل عن عدد السنوات التي سيستغرقها تعلم كيفية كتابة كود bash .... الأخطاء المتغيرة غير المنضمة في Virtualenv قديمة جدًا ومن السهل إصلاحها وأيضًا تجنبها في المستقبل عن طريق إضافة سطر بسيط إلى الاختبارات الافتراضية: set -euox pipefail .

ناهيك عن عدد السنوات التي سيستغرقها الإصلاح للوصول إلى جميع توزيعات Virtualenv الموجودة هناك حيث يتم تعبئتها عادةً في debian و ubuntu و centos و rhel و fedora .... :( :( :(

هل سيعترف مشرفو المشروع بوجود هذه المشكلة؟

لا أعرف ولكن بالنظر إلى أننا حصلنا أيضًا على علاقات عامة عمرها أسبوعين تقريبًا. الجواب الأكثر احتمالا هو أنهم لا يقدمون ... إرسال.

سأحاول إحداث بعض الضجيج على irc و twitter ، وربما حتى القائمة البريدية. ربما يمكننا دمج الإصلاحات.

Virtualenv هو الشيء الوحيد الذي يمنعني من جعل bashrict Mode افتراضيًا في وظائف CI.

+1

أعتقد أن مجرد تعطيل nounset في بداية البرنامج النصي واستعادته في النهاية قد يكون أكثر قوة بدلاً من محاولة تعليم python devs كيفية bash :)

@ jakub-bochenski ربما يمكنك أيضًا المساعدة في كتابة بعض التعليقات على irc. دعونا نرى ما إذا كان بإمكاننا الحصول على عدد كافٍ من المستخدمين لتنبيه مطور Virtualenv core.

ssbarnea غير متأكد من ذلك ، لم أسجل الدخول إلى IRC منذ

تنهد...

+1

لقد قمت بإرسال بريد إلكتروني إلى pypa-dev منذ 7 أيام ولم أتلق أي رد. بالأمس أيضًا نشر أحد الأشخاص أن برنامج Win32 الثنائي المثبت يحتوي على حصان طروادة ، ولم يتم الرد مرة أخرى. آمل فقط ألا يكون حصان طروادة في التوزيعة حقًا ، وليس أن يؤثر علي.

راجع https://groups.google.com/forum/#!forum/pypa -dev

ركض في هذا اليوم ، برزت أنه كان خطأ في رمز بلدي في مكان ما.
: +1: لتضمين set -euo pipefail في اختبارات الوحدة.

للرجوع إلى الرابط المباشر للمناقشة المذكورة أعلاه هو: https://groups.google.com/d/topic/pypa-dev/8iVHDOqsj9M/discussion

pfmoore كتب

لقد أجبت بالفعل بمزيد من التفاصيل حول قائمة مستخدمي virtualenv ،

.. التي تحولت إلى قائمة python-virtualenv ؛ https://groups.google.com/d/topic/python-virtualenv/5xKG8KoBl6g/discussion

FWIW ، الحل الذي أستخدمه في .devkit هو تعيين VIRTUAL_ENV_DISABLE_PROMPT=true على السطر source . إنه يعمل بشكل أفضل مع حالة الاستخدام الخاصة بي من تعيين PS1 ، لأنه يعطل سلوك إعداد المطالبة تمامًا.

pjeby @ jakub-bochenskijpuskar @ axd1967 يرجى ملاحظة أن لدينا بالفعل إصلاح خطأ لهذا ولكن لدمجها نحتاج إلى مراجعة ودمج اثنين من العلاقات العامة الأخرى ، وذلك فقط لأننا نريد ونحتاج إلى تحسين اختبار التفعيل- جناح.

1. https://github.com/pypa/virtualenv/pull/1089 - تمكين اختبار CI على py36 وإسقاط py33
2. https://github.com/pypa/virtualenv/pull/1087 - تمكين استخدام البرنامج النصي test_activate.sh على CI
3. https://github.com/pypa/virtualenv/pull/1078 - إصلاح PS1 غير منضم قيد التنشيط

ربما سترى أن الأخيرين لا يجتازان اختبارات CI ، ولهذا السبب نحتاج إلى دمج الآخرين أولاً.

يرجى مراجعتها / التعليق عليها ، فهي مهمة أكثر من أي مشروع آخر لأن Virtualenv تفتقر إلى بعض قوة المراجعة ، وهذا أحد الأسباب التي دفعتني إلى أن أصبح مشرفًا على https://groups.google.com/d/msg/pypa -dev / SgK9vlu93BY / F2_8OoKAAgAJ -

ومع ذلك ، يبدو أننا سنحتاج إلى أكثر من واحد حيث لن أتمكن من مراجعة التغييرات الخاصة بي.

ssbarnea هل تطلب منا أيضًا الحصول على أذونات المراجع ، أم مجرد إجراء مراجعة وترك +1 / تعليق؟

تحرير: لا تهتم على ما يبدو يمكن لأي شخص مراجعة العلاقات العامة

1 فعل 2 آخر للذهاب :)

هل يمكننا الحصول على ETA عندما يتم دمجها وإتاحتها للجمهور؟

تحرير: لا تزال هذه المشكلة تواجه ، وقد أسقطت تصميمًا هذا الصباح.

لقد تعرضت أيضًا للعض من هذا ، عند العمل على إنشاء البرنامج النصي لحل معالجة الصور المستند إلى AWS lambda: https://github.com/awslabs/serverless-image-handler/blob/master/deployment/build-s3 -dist.sh

لقد استخدمت الحل البديل VIRTUAL_ENV_DISABLE_PROMPT=true source env/bin/activate .

duanekingrobinbowes هناك عدم وجود سلطة صيانة حول virtualenv وإذا كنت ترغب في مساعدة معالجة هذه المسألة يرجى قراءة والتعليق على https://groups.google.com/forum/#!topic/pypa -dev / SgK9vlu93BY

انطباعي هو أن فريق PYPA سيتفاعل مع هذا فقط إذا حصل على تعليقات المجتمع الكافية.

FTR ما زلنا ننتظر الدمج على # 1087

خمن ما هو المثال الأول لاستخدام الوضع الصارم غير الرسمي Bash |

نعم ، إنها لعبة python 2 virtualenv.

نظام التشغيل Ubuntu 16.04.0

• لا يعمل: VIRTUAL_ENV_DISABLE_PROMPT = صحيح
• يعمل: https://github.com/bogdando/tripleo-ci/commit/318d17a9e2d94723aa1a0d8e2a9ee345e67032ae

لاحظ أن استخدام bogdando / tripleo-ci @ 318d17a سيؤدي إلى تجاوز الوضع إلى -u حتى لو لم يكن نشطًا من قبل. ليس بالضبط بناء أفضل ممارسة.

سيحافظ هذا على الحالة السابقة:

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

أقترح الآن استخدام التصحيح (استخدم bash أو قم بتغييره وفقًا لاحتياجاتك)
سيبدأ في الفشل (كسر التشغيل) بمجرد أن يتمكن المؤلفون أخيرًا من نشر هذا الإصلاح ، مما يمنحك مؤشرًا واضحًا على إجراء التغيير

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"

ثابت الآن https://github.com/pypa/virtualenv/pull/922