اتضح أن python -m pip "يعمل" ، إلا أنه يقوم بتثبيت الحزم في Virtualenv الأصلي.

(outer) [vagrant@vagrant-arch ~]$ deactivate 
[vagrant@vagrant-arch ~]$ source virtualenv/bin/activate
(virtualenv) [vagrant@vagrant-arch ~]$ python -m pip install tox

هو venv النشط ، يجب أن يحتوي على سموم

(virtualenv) [vagrant@vagrant-arch ~]$ ls virtualenv/lib/python3.6/site-packages/
(virtualenv) [vagrant@vagrant-arch ~]$ ls virtualenv/bin/
activate  activate.csh  activate.fish  python  python3

ولكن تم تثبيت السم على Virtualenv الأصلي

(virtualenv) [vagrant@vagrant-arch ~]$ ls outer/lib/python3.6/site-packages/
__pycache__      pip                  pkg_resources  pluggy-0.5.2.dist-info  py-1.4.34.dist-info  setuptools-36.6.0.dist-info  six.py  tox-2.9.1.dist-info          virtualenv.py       wheel
easy_install.py  pip-9.0.1.dist-info  pluggy         py                      setuptools           six-1.11.0.dist-info         tox     virtualenv-15.1.0.dist-info  virtualenv_support  wheel-0.30.0.dist-info
(virtualenv) [vagrant@vagrant-arch ~]$ ls outer/bin 
activate  activate.csh  activate.fish  activate_this.py  easy_install  easy_install-3.6  pip  pip3  pip3.6  python  python-config  python3  python3.6  tox  tox-quickstart  virtualenv  wheel

لقد حاولت إنشاء venv مشابه باستخدام الخيار --copies ، لكن لم يكن له أي تأثير.

انقر هنا أيضًا: https://github.com/pre-commit/pre-commit/issues/755

أظن أن هناك حاجة إلى إصلاح من جانب venv للقيام برقصة .real_prefix . سأحقق في هذا النهج كحل بديل لمجرد pre-commit

يبدو أن هذه هي مشكلة bpo: https://bugs.python.org/issue30811

أظن أن هناك حاجة إلى إصلاح من جانب venv للقيام برقصة .real_prefix .

ليس من الواضح بالنسبة لي من يجب أن يكون مسؤولاً عن الإصلاح. هل يجب أن يكتشف venv أنه يتم تنفيذه من داخل virtualenv ، أم يجب أن ينشئ virtualenv بيئة متوافقة مع venv ؟ من ناحية أخرى ، يسبق venv virtualenv venv . من ناحية أخرى ، يعد venv جزءًا من المكتبة القياسية.

بغض النظر ، إليك الحل البديل الذي أجريته حاليًا في تطبيق Tox-venv:

https://github.com/tox-dev/tox-venv/blob/58401663fda66dfba4f344553525c73d57432d5e/src/tox_venv/hooks.py#L10 -L49

يمكن تحسين اكتشاف المسار القابل للتنفيذ ، حيث إنه يبحث حاليًا عن python3 . على سبيل المثال ، قد تريد python3.6 ، لكن python3 نقطة إلى python3.4 .

اخترت حلاً مشابهًا: https://github.com/pre-commit/pre-commit/blob/805a2921ad0d34698433972c6fcb1a6dca47191d/pre_commit/languages/python_venv.py#L13 -L39

(الاختلاف الرئيسي هو أن الالتزام المسبق يقوم بالفعل ببعض التسوية ، لذلك أستخدم bin/$(basename exe) بدلاً من bin/python3 )

إيه ، نعم بشكل عام أشعر أننا يجب أن نكون متوافقين مع venv.

gaborbernat وفقًا لـ berdario / pew # 173 ، لا يبدو أن هذا هو الحال. uranusjr الرعاية

تم وضع علامة على هذه المشكلة تلقائيًا على أنها قديمة نظرًا لعدم وجود نشاط حديث لها. سيتم إغلاقه في حالة عدم حدوث أي نشاط آخر. فقط أضف تعليقًا إذا كنت تريد إبقائه مفتوحًا. شكرا لمساهماتكم.

1343

gaborbernat أعتقد أنه يجب إعادة تسمية المشكلة إلى "تشغيل venv داخل virtualenv" لتمييزها عن # 1339.

FranklinYu هل العنوان المحدث كافٍ؟

أصبح هذا عفا عليه الزمن مع # 1366 الآن على قدم وساق.