Virtualenv: تضمين البرامج النصية للمكتبة القياسية في البرامج النصية الخاصة بـ virtualenv

هل لا يزال هذا يحدث بعد إجراء إعادة صياغة pyenv؟

ما الذي يتم تنفيذه عند تشغيله قبل أو بعد إعادة صياغة pyenv؟

لدي شعور أن هذا له علاقة بـ pyenv.

هل لا يزال هذا يحدث بعد إجراء إعادة صياغة pyenv؟

نعم.

ما الذي يتم تنفيذه عند تشغيله قبل أو بعد إعادة صياغة pyenv؟

نظرًا لأنه تم تحديد system Python حيث لم يتم تثبيت حزمة apt مع 2to3 ، كما تقول

pyenv: 2to3: command not found

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

في كلتا الحالتين.

لدي شعور أن هذا له علاقة بـ pyenv.

pyenv غير ذي صلة. كان السلوك المتوقع بالنسبة للثاني which لإرجاع الرقاقة virtualenv كما هو الحال مع python . الخطأ هو أن virtualenv لا يُنشئ واحدًا. (اعتقدت أن هذا كان واضحًا. ربما لا).

آه ، حسنًا ... ما هو PATH بعد التنشيط؟

(أنا لست على جهاز حيث يمكنني محاولة إعادة إنتاج هذا الآن)

(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

كحل بديل ، يمكنك استخدام python -m lib2to3 داخل virtualenv الخاصة بك ، بوظائف مكافئة.

/ cc other @ pypa / virtualenv-committers إذا كانوا يعتقدون أن إضافة نصوص من المكتبة القياسية إلى virtualenv عند إنشائها ، فكرة جيدة.

أنا متناقض.

أنا -0.5. إنها فوضى إضافية لم يتم الإبلاغ عنها كمشكلة حتى الآن ، لذلك أفترض أن الحاجة نادرة. لست مقتنعًا بأن اقتراب Python 2 من موسوعة الحياة يحدث فرقًا هنا. البرامج النصية الإضافية ليست موجودة على PATH في بيئة غير افتراضية على Windows أيضًا ، لذلك ليس مثل توقع وجودها عالميًا.

أعتقد أن هذا يجب أن يعمل كنهج عام. يجب أن تكون جميع التطبيقات في البيئة المضيفة متاحة على مستوى البيئة الافتراضية.

لست مقتنعًا بأن اقتراب Python 2 من موسوعة الحياة يحدث فرقًا هنا.

+1

هذا ليس شاغلي هنا أيضًا. :)

البرامج النصية الإضافية ليست موجودة على PATH في بيئة غير افتراضية على Windows أيضًا

أوه. أليست هذه موجودة في الدليل Scripts/ ؟ كنت أفهم أن مثبّتي python.org الحاليين يضيفون هذا الدليل إلى PATH وبالتالي يمكن تنفيذها.

يجب أن تكون جميع التطبيقات في البيئة المضيفة متاحة على مستوى البيئة الافتراضية.

Uhm ... "التطبيقات" غامضة بعض الشيء هنا - هل تشير إلى البرامج النصية أو أي شيء آخر؟ هل يمكنك توضيح ما تعنيه؟

لاحظ أنه إذا قمنا بذلك ، فأنا قوي -1 فيما يتعلق بتضمين جميع البرامج النصية من البيئة المضيفة على أي حال ومتناقضة في تضمين تلك التي تدعمها المكتبة القياسية.

أوه. أليست هذه في البرامج النصية / الدليل؟

لا ، كل ما في Scripts عبارة عن أغلفة لنقاط الدخول للمكتبات المثبتة (pip ، easy_install والعجلة في التثبيت الأساسي). إذا نظرنا إلى أبعد من ذلك ، فإن 2to3.py موجود في Tools/scripts (مع مجموعة مختلطة إلى حد ما من أكثر من 60 نصًا آخر) ، ولكن هذا الدليل لم يتم وضعه على PATH ، حتى لو يختار المستخدم "إضافة Python إلى المسار الخاص بك".

لاحظ أنه إذا قمنا بذلك ، فأنا قوي -1 فيما يتعلق بتضمين جميع البرامج النصية من البيئة المضيفة على أي حال ومتناقضة في تضمين تلك التي تدعمها المكتبة القياسية.

كحد أدنى ، أود أن أزعم أنه لا ينبغي لنا إضافة المزيد إلى PATH مما يفعله التثبيت الأساسي. مما يعني أنه حتى لو فعلنا ذلك ، فإننا لا نقوم به على Windows.

قام pradyunsg بتغيير العنوان تضمين البرامج النصية للمكتبة القياسية في حاوية Virtualenv / تضمين البرامج النصية للمكتبة القياسية في نصوص Virtualenv منذ ساعتين

فقط مشيرا إلى أن هذا هو نطاق تغيير طفيف. كان OP مهتمًا على وجه التحديد بـ 2to3 ، وعلى وجه الخصوص أن تنشيط Virtualenv لم يؤثر على النظام 2to3 . سواء كان ذلك مهمًا لا يمكنني التعليق عليه (نظرًا لأنني جادلت لعدم حدوث ذلك على Windows ، فليس لدي خبرة ذات صلة في Unix لأقول ما إذا كنت أشعر أن هذه مشكلة). ولكن بدون معرفة ما هي البرامج النصية الأخرى "نصوص مكتبة قياسية" لا يمكنني التعليق إذا كانت هذه نقطة مهمة.

حسنًا ، من المحتمل أن يكون pyvenv "برنامج نصي للمكتبة القياسية" آخر ، وأنا متأكد من أننا لا نريد تظليل إصدار النظام من ذلك باستخدام إصدار يقوم بتشغيل venv من بيئة virtualenv (لأن هذا يتسبب فقط في حدوث مضاعفات بدون فائدة عملية).

كان OP ... مهتمًا ... على وجه الخصوص بأن تنشيط Virtualenv لم يلقي ظلالاً على النظام 2to3.

(لست متأكدًا مما تضعه هذه العبارة في فمي ، يمكن تفسيرها في كلا الاتجاهين.)

من أجل الوضوح ، أطلب virtualenv لإنشاء رقاقة مقابل 2to3 .

(دعني أقوم بتعديل المنشور الأصلي بالسلوك المتوقع ، أرى أن حذفه يسبب ارتباكًا.)

(دعني أحرر المنشور الأصلي بالسلوك المتوقع)

منجز. لقد أوضحت أيضًا سبب توقع المستخدم أن يكون على PATH .

لست متأكدًا مما تضعه هذه العبارة في فمي

آسف لتحريف تعليقاتك وشكرا للتوضيح! (يبدو أنني فهمت بشكل صحيح ما كنت تطلبه ، لقد أعدت صياغته بشكل سيء ...)

لقد أوضحت أيضًا سبب توقع المستخدم أن يكون على PATH.

الارتباط الذي أشرت إليه مربك بعض الشيء. يبدو أن المستخدم لديه عملية تعمل على Trusted and xenial ، ولكن ليس على الأجهزة الإلكترونية. ليس من الواضح بالنسبة لي سبب حدوث ذلك إذا كانت المشكلة في virtualenv. (ملاحظة: هذا استطرادي - بصرف النظر عن ذلك ، فمن الواضح أن Virtualenv لا تنسخ 2to3.py ، لذا فإن مناقشة ما إذا كان ينبغي لنا أن تكون صالحة حتى لو كانت المشكلة الأصلية أكثر دقة).

أطلب Virtualenv لإنشاء رقاقة لـ 2to3.

لاحظ أننا لن ننشئ رقاقة أبدًا. كل ما سنفعله هو نسخ البرنامج النصي 2to3.py . إذا كانت هناك حاجة إلى رقاقة (أعتقد أن هذا شيء من نوع pyvenv) فلن نكون نحن من تعاملنا معه.

لا ، كل ما في البرامج النصية عبارة عن أغلفة لنقاط الدخول للمكتبات المثبتة (pip ، easy_install والعجلة في التثبيت الأساسي).

اووووووووووو. تمام.

فقط مشيرا إلى أن هذا هو نطاق تغيير طفيف.

لا أعتقد أن 2to3 عبارة عن ندفة ثلجية خاصة - إذا أضفنا ذلك ، أتوقع أن يأتي شخص ما ويسأل عن الباقي. يجب علينا إما أن نفعل هذا بشكل كامل أو لا نفعله على الإطلاق. أن تكون عالقًا في منتصف الطريق ليس شيئًا نريده هنا.

(أنا أكره واجهة مستخدم الجوال)

إنه "خاص" لأنه مدعوم من قبل المكتبة القياسية وهو في PATH لتثبيت Linux قياسي.
لا توجد في الواقع العديد من الأدوات الأخرى مثل هذه. بخلاف 2to3 ، فهو pydoc و idle و 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

(أيضًا python-config الذي تمت إعادة توجيهه بالفعل)

آه ، شكرًا على التوضيح @ native-api! مقدر جدا. جنبًا إلى جنب مع شرح pfmoore لكيفية أن هذه مشكلة لا تتعلق بنظام Windows ، فهذا يساعدني على فهم الأمر. :)

ما زلت متناقضًا بشأن تضمينها.

بخلاف 2to3 ، إنه pydoc و idle و pyvenv

سأكون فضوليًا لمعرفة من اختار تلك القائمة. هل هو على وجه التحديد pyvenv؟ لا يبدو أن Ubuntu (bash على Windows ، وصورة عامل إرساء مثبت عليها python3) تحتوي على 2to3 افتراضيًا ، على الرغم من أن صورة عامل إرساء Python لها نفس الثنائيات التي ذكرتها (بالإضافة إلى pip و easy_install و wheel ، والتي تأتي من الحزم المثبتة). يبدو أنه يعتمد على التوزيع قليلاً :- (على الأقل تبدو قائمة الثنائيات ذات الصلة متسقة.

راجع للشغل ، كما قلت أعلاه ، حتى لو قمنا بإجراء هذا التغيير ، فإنني أنصح بشدة بعدم تضمين pyvenv.

لا يبدو أن Ubuntu (bash على Windows ، وصورة عامل إرساء مثبت عليها python3) تحتوي على 2to3 افتراضيًا

هذا لأنه في Ubuntu ، يتم نقل 2to3 إلى حزمة منفصلة:

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

من خلال "تثبيت Linux القياسي" ، كنت أعني المنطق المتأصل في برنامج Python الخاص ببناء Linux ، دون تدخل التوزيعات - على سبيل المثال إذا قمت بالتثبيت من المصدر (وهو ما يفعله pyenv ).

يمكنني تناول هذا الأمر وسأحاول العمل عليه.

ملاحظة ، سيحل هذا محل الاختراق الحالي لإضافة pydoc كجزء من نص التنشيط.