اقتراح طموح!

دعم تكوين ini (تكوين ini عام موجود في منزل المستخدمين)

ضع في اعتبارك استخدام appdirs (أو ما شابه) لاكتشاف التكوين في المواقع المفضلة للنظام الأساسي.

appdirs يمكن أن يكون خيارًا جيدًا ، على الرغم من أننا سنحتاج إلى بدء عمل بيع الأشياء في الحزمة الخاصة بنا. لكي نكون منصفين ، تم تنفيذ 70٪ من هذا بالفعل ، لن نحتاج سوى إلى إعادة تنظيم أفضل.

لماذا البائع بدلا من الاعتماد عليه فقط؟ (لا يعني ذلك أنه من الصعب البيع ، إنه مجرد ملف واحد). IMO ، نحن بحاجة حقًا إلى قبول أنه (مع استثناء ملحوظ لـ pip) يجب أن تُبنى أدوات التغليف تمامًا مثل أي تطبيق آخر. إذا كان وجود التبعيات أمرًا صعبًا بدرجة كافية بحيث تتجنب تطبيقات PyPA لها ، فماذا يقول ذلك عن مدى نجاحنا في تسهيل تطوير التطبيقات على مستخدمينا؟

(عذرًا ، لا أثير نوعًا من النقاط المهمة حول virtualenv هنا ، فأنا أرى الكثير من الأشخاص يقولون "إضافة تبعية PyPI ليست مشكلة كبيرة" ، ثم أدوات PyPA التي أعمل عليها في بيع الأشياء تجعلني أتساءل ...) .

أعتقد أنه بدون بيع ميزة المترجم المتقاطع سيكون صعبًا. على سبيل المثال ، إنشاء بيئة افتراضية لمترجم ليس مثبتًا عليه virtualenv.

PYTHONPATH = / t / path / to / virtualenv.whl python -m virtualenv

أه هذا يعني أننا لا نستطيع الاعتماد على أي حزم إضافية من virtualenv. بما أننا سنوفر تطبيق zipapp ، ما هي حالات الاستخدام التي يتيحها ذلك؟

gaborbernat هل تقصد الخيار -p ؟ أظن ذلك. يبدو أنه بالضبط نوع الموقف الذي كانت zipapps تهدف إلى المساعدة فيه ، ولكن لم يقم أحد على الإطلاق بالكثير من أجل توضيح التفاصيل لجعلها تعمل بشكل جيد.

من pradyunsg :

أه هذا يعني أننا لا نستطيع الاعتماد على أي حزم إضافية من virtualenv

في الواقع ، كما قال gaborbernat ، من المحتمل أن يشير الخيار -p إلى ما يلي :- (لكني أتساءل لماذا نحتاج إلى خيار "العجلة على PYTHONPATH " بالإضافة إلى zipapp - خاصة بالنظر إلى تلك العجلات على PYTHONPATH غير مدعومة بشكل عام (نستخدمها داخليًا في virtualenv بسبب أسباب تمهيد النقطة المعتادة - النقطة هي استثناء إلى حد كبير لكل شيء ؛-))

فترة سماح لمدة عامين للدعم

همم...

ما يقلقني هنا هو أن تأثيرات الشبكة لهذا قد تتسبب في تباطؤ اعتماد إصدارات أحدث من Python والانفجار التوافقي لعدد Pythons المدعومة. يناقش CPython إيقاع إصدار مختلف لـ 3.9 ، لذلك قد يكون عامين أطول مما قد يكون لبعض الإصدارات من المطورين الأساسيين.

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

(تأمل في IronPython و Jython في وقت ما - أي نقاط أخرى يجب أن ندعمها؟)

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

أولاً ، دعم تكوين ini (تكوين ini عام موجود في منزل المستخدمين) ،

أنا متحيز - أود حقًا أن أرى هذا TOML بدلاً من ذلك. :)

(لم أقم بمعالجة هذا الأمر بالكامل حتى الآن حيث يجب أن أذهب إلى مكان ما - لكن هذا يبدو وكأنه هدف عام رائع!)

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

تفضل المدمج في venv: إذا كان للبيثون الهدف venv ، فسننشئ البيئة باستخدام ذلك (ثم نقوم بعمليات لاحقة على ذلك لتسهيل الضمانات الأخرى التي نقدمها)

لست متأكدًا من أنني أفهم الأساس المنطقي لذلك. ويبدو ان الامر سيجعل صيانة virtualenv أصعب وأنه سيجعل السلوكيات أكثر صعوبة بالنسبة للمستخدمين النهائيين لفهم. يسير setuptools بالفعل في الاتجاه الآخر من خلال محاولة استيعاب distutils بدلاً من الاستمرار في تصحيحه.

pganssle النطاق مختلف ومساحة المشكلة أيضًا. مشكلة virtualenv هي أن الأنظمة غالبًا ما تضع قيودًا إضافية على حزم النظام ، لذلك تقوم القرد بتصحيح venv المدمج للالتزام بهذه القيود. سيكون تكرار كل هذه الأشياء صعبًا ، انظر على سبيل المثال # 1362.

FWIW أعتقد أن استخدام الحزمة المدمجة في venv للعزل هي الفكرة الصحيحة ، فهي مضمنة في المترجم الفعلي (بدلاً من distutils التي هي مجرد وحدة stdlib) لذا يمكنها القيام بأشياء أكثر نظافة بكثير من virtualenv يمكن.

لن يحتاج برنامج Virtualenv أيضًا إلى monkeypatch أي شيء ، بل سيستخدم فقط واجهة برمجة التطبيقات العامة التي يجب أن تكون جيدة.

FWIW أوصي بالتحقق من فرع إعادة الكتابة في virtualenv القديم ، لقد فعل الكثير من هذه الأشياء بالفعل.

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

أيضًا ، لا يزال بإمكانك الاعتماد على الأشياء "بشكل طبيعي" وما زلت تستخدم zipapps ، ما عليك سوى البيع داخل zipapp نفسه. أوصي بالابتعاد عن إعادة التنفيذ في ظل خيار python المستهدف ، فهذا أمر سيء ويمكن القيام به بشكل أكثر نظافة.

697 - العلاقات العامة الأقدم dstufft

PYTHONPATH = / t / path / to / virtualenv.whl python -m virtualenv

OTOH ، ربما لا ينبغي لنا القيام بذلك على أي حال - https://www.python.org/dev/peps/pep-0427/#is -it-possible-to-import-python-code-direct-from- ملف عجلة

pradyunsg إذن ، هل هناك أي طرق أخرى

من المحتمل أن يكون Bootstrapping pip على ما يرام - إنه ما يستخدمه virtualenv الآن ¹ . ولكن أود أن نوصي بشدة فقط استخدامه لنقطة، وليس كوسيلة لتشغيل virtualenv نفسها.

¹ لكنني أتجنب أي وظيفة معقدة - استخدام عجلة على PATH لتثبيت نقطة من تلك العجلة مضمون إلى حد كبير ليكون جيدًا. ولكن قد تواجه مشكلات إذا كنت ، على سبيل المثال ، تصل إلى الإنترنت باستخدام مثل هذه العجلة ، حيث أعتقد أن الشهادة تحتاج إلى حزمة الشهادات المضمنة الخاصة بها كملف فعلي (لكن قد أكون مخطئًا ، فهذا لم يسبب لي مشكلة أبدًا ، لكنني أعرف get-pip.py يستخرج الشهادات من العجلة بشكل صريح لمعالجة هذه النقطة.

أي سبب لعدم شحن النقطة بـ zipapp ؟ سيؤدي ذلك إلى تجنب هذه الحاجة كما أفهمها ، ويتم دعم zipapp باستخدام python 2.7 🤔

gaborbernat هل جربته؟ هل يعمل؟ إذا كان النهج الذي حددته يعمل على النوافذ ، فليس لدي أي مخاوف أولية ولكن من المحتمل أن يكون لدى dstuff وهو ما يعني أن الأبسط هو الأفضل

أي سبب لماذا لا نقوم بشحن Pip كـ zipapp؟

لأنه في حالات معينة ، لن يتم تشغيل النقطة مباشرة من ملف مضغوط (أو عجلة ، إنها نفس الشيء) ، كما قلت أعلاه. 99٪ (تنبيه - رقم مكون) من الوقت ، يعمل ، لكن في بعض الأحيان حقيقة أن حزمة الشهادة تحتاج إلى أن تكون ملفًا حقيقيًا مهمة.

من المحتمل أن يعمل بشكل جيد تجميع النقطة باعتبارها shiv على الرغم من ذلك ، حيث يقوم shiv بفك ضغط zipapp قبل تشغيله ، على وجه التحديد لتجنب حالات الركن التي يتم فيها الجري من فواصل zip. لم يجربها أحد على حد علمي.

كالعادة ، الأسباب الرئيسية لعدم حدوث ذلك هي:

1. لم يفكر أحد في ذلك.
2. لم يكن لدى أحد الوقت / الدافع للقيام بذلك.
3. النهج الحالي يعمل بشكل جيد ، وهناك سمكة أكبر للقلي.

إذن ، هل هناك طرق أخرى لتمهيد bootstrapping pip دون وضع العجلة على المسار؟

لا أعتقد أننا بحاجة إلى ذلك هنا - Virtualenv تستخدم عجلة الأنابيب لتثبيتها من نفسها IIRC ، والتي يجب أن تعمل بشكل جيد. كما قال pfmoore ، الشيء "الإضافي" الوحيد الذي تقوم به get-pip.py هو فك الشهادات وتوفير مسار لها. نظرًا لأن قاعدة استخدام virtualenv لن تصل إلى الشبكة ، فنحن لسنا بحاجة إلى القيام بأي شيء جديد هنا.

النهج الحالي يعمل بشكل جيد ، وهناك سمكة أكبر للقلي.

هذا ، أكثر بكثير من المنظمة البحرية الدولية الأخرى. يمكننا ولكن هناك قضايا أكثر تأثيرًا يجب معالجتها. :)

لقد كان لدي علاقات عامة في وقت ما أنشأت pip كتطبيق مضغوط ، وقد نجح ولكن كان على IIRC I إجراء تغييرات على pip لجعله يعمل بكامل طاقته.

قد يكون هذا معقدًا بعض الشيء الآن لأن النقطة تستدعي نفسها كعملية فرعية لنفسها لـ PEP 517. لست متأكدًا ولكن هذا بالتأكيد يستحق الاستكشاف.

في هذه المرحلة ، سيكون shiv (أو خيار استخراج ذاتي آخر) أكثر ملاءمة للنقطة من محاولة تشغيل النقطة في zip-runnable. لكن لا أعتقد أن هذا أمر مهم بشكل خاص في هذه المرحلة. ensurepip يذهب بالفعل إلى طريق العجلة على المسار ، فلماذا لا تفعل الشيء نفسه. يمكن استكشاف نظام التمهيد البديل للنقطة بعد أن نقلي جميع الأسماك الكبيرة ، ومن المحتمل أن نساهم مرة أخرى في stdlib.

يمكن استكشاف نظام التمهيد البديل للنقطة بعد أن نقلي جميع الأسماك الكبيرة

تبدو وكأنها خطة [خطة نتبعها بالفعل. ؛)]

شكرًا على الروابط ، بناءً على التعليقات ، بدأت بعض الأعمال الأولية على https://github.com/gaborbernat/virtualenv/tree/rewrite/src/virtualenv. تتمثل الخطة في إدخاله في شكل إصدار خلال الشهر التالي (ويكون لديك أسبوع من المراجعة المفتوحة قبل ذلك). بناءً على تأثير التغيير ، أخطط لإصداره 20.0.0 .

+1 لاستخدام venv إن وجد. هذا من شأنه أن يجعل حالة استخدام PyPy أبسط.

لذا فقد وصلت إعادة الكتابة إلى حالة أشعر فيها بالراحة عند إلقاء نظرة عليها وإبداء بعض الملاحظات. يُرجى التواصل معي إذا كان لديك بعض وقت الفراغ للمساعدة في ذلك ؛ الخطة هي أن يتم إصدارها بحلول نهاية الشهر ملاحظة https://github.com/pypa/virtualenv/milestone/7 لا تزال بحاجة إلى التنفيذ ، ومع ذلك ، فإن الفكرة الأساسية موجودة.

ملاحظة. إنشاء تعليق العلاقات العامة تحت https://github.com/pypa/virtualenv/pull/1481/

طلب الميزة: توفير آلية لتحديد متغيرات البيئة المخصصة ، على سبيل المثال عن طريق وضع ملف env.txt في دليل venv bin بالتنسيق القياسي:

VARNAME=value
OTHERVAR=othervalue

لا أعتقد أنني أفهم حالة الاستخدام الخاصة بك؟ كيف يمكن استخدام متغيرات البيئة هذه ، وتعيينها ، ومتى؟

تعديل. NM. أرى أنك وسعت على https://github.com/pypa/virtualenv/issues/1124.

تحديث صغير لقد تمكنت من إغلاق معظم مشكلات الحظر ، بخلاف مشكلتين لا تزالان بحاجة إلى بعض الحب: يتضمن الاختبار الرؤوس + التخزين المؤقت لمكالمات استجواب python مع بعض القفل المطبق على بيانات التطبيق ، حتى نتمكن من إنشاء بيئات افتراضية بالتوازي (لمواقع مختلفة). بالوتيرة الحالية قد أتأخر بضعة أيام ... لكن بالتأكيد سأخرج بحلول السابع من فبراير.

ما هي خطتنا فيما يتعلق بالتطبيق؟ هل سيكون لدينا إصدار تجريبي قبل الإصدار الرئيسي؟

نعم ، تريد الحصول على شيء ما يوم الاثنين ... ثم اترك مؤقتًا أسبوعًا للحصول على التعليقات والإصلاحات ... ثم استبدل الرئيسي بإعادة الكتابة والإفراج.

لست متأكدًا بنسبة 100٪ من أن الأسبوع سيكون كافيًا ويجب علينا بالتأكيد التواصل عبر قنوات متعددة نريد من الأشخاص تجربة الإصدار التجريبي.

الكلمة الرئيسية كانت هناك مؤقتًا . أنا متفائل هنا ، نظرًا لمقدار الجهد الذي بذلته ، فأنا لا أتوقع مشكلات كبيرة ، لكن 🤷‍♂

Virtualenv 20.0.0 beta1 متاح .

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