Pip: محلل جديد: الطرح وحلقات الملاحظات وتدفق التطوير

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

أحد الأسباب هو أنك إذا كنت تشارك المزيد من التعليمات البرمجية ، فستكون هناك فرصة أقل للكسر عند تبديل السلوك الجديد وإيقافه ، لأنك ستمارس هذا الرمز المشترك في كلتا الحالتين ولن يكون لديك العديد من الاختلافات المحتملة في السلوك للتعامل معها.

قد يتضمن ذلك عبارات حث المستخدم على اتخاذ إجراء لمطالبتهم بتجربتها وتقديم الملاحظات

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

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

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

من حيث git / GitHub ، من المحتمل أن يكون هذا هو أول تطبيق "تجريبي" للميزة ضمن النقطة

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

لقد أمضيت حوالي 60 دقيقة (أعدت إعادة إعادة إعادة) في كتابة هذا المنشور ، لذا سأذهب الآن لإلقاء نظرة على الأماكن في نيويورك! إذا لم تر ردًا سريعًا مني ، فذلك لأنني سأكون في وضع السائح.

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

قطعا! هذا هو 80 ٪ من سبب وضع # 5051 في المقدمة - أعتزم سداد الكثير من الديون الفنية التي تراكمت لدينا في منطق البناء الخاص بنا حتى يصبح من الأسهل إعادة استخدامه (كل؟). مجموعة من الكود يجب أن تكون: حريق: وأنا أوافق على أنه يجب بالتأكيد إعادة استخدام الباقي بقدر المعقول.

لم نميل إلى تركها "إيقاف التشغيل افتراضيًا ، وتمكين تجربتها" ، إذا كان هذا ما تعنيه

نعم ، في الواقع. أنا ألمح أيضًا إلى تدفق التطوير هنا - سيكون من المقبول IMO دمج البنية التحتية الفارغة (الفئات التي تحتوي على مجموعة من الأساليب التي لا raise NotImplementedError() في العلاقات العامة اللاحقة) أو لا تغطية جميع الحالات (تنفيذ نصف مخبوز) في الفرع master طالما أنه يُستخدم فقط خلف العلامة التي يُشار إليها صراحةً على أنها "تجريبية / ألفا".

إعادة: ردود الفعل

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

بالنظر إلى التغييرات "الرئيسية" الأخيرة ، أعتقد أن معظم التعليقات التي تلقيناها كانت تفاعلية - من المستخدمين الذين أدركوا مشكلات في سير العمل عند تعطله ، ثم التواصل لإبلاغنا بذلك. ربما لم يكن لدى الكثير منهم الوقت للمساعدة في تحديد تفاصيل الوظيفة الجديدة ، والتي تسبب الكثير من الاحتكاك. لقد كلفنا هذا أيضًا الكثير من "ميزانيتنا المتضخمة" [1] ، والتي لا أريد إنفاق المزيد منها ، نظرًا لأن Python Packaging لم يتبق لها الكثير على أي حال [2].

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

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

إعادة: المنح

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

FWIW ، PSF لديها عقد مستمر للمساعدة في اكتشاف الاتصال المتعلق بـ PyPA / التغليف مع Changeset Consulting ، فربما يمكننا الاستفادة من ذلك؟

لا أقصد عمدًا الإشارة إلى @-الإشارة إلى الأشخاص لأن هذا مبكر إلى حد ما في حالة التخطيط لإضافة المزيد من الأشخاص في المحادثة.

الهوامش:

1. مصطلح لطيف حقًا استخدمه @ pganssle والذي سأستخدمه بالتأكيد.
2. هذا هو السبب في أنني وضعت رقم 3164 على المحك الخلفي ، على الرغم من وجود تنفيذ لحزمة "pip-cli" المقترحة هناك وتوصلنا إلى إجماع معقول حول الكيفية التي نريد أن تبدو بها عملية الطرح.

أنا شاب ، غبي ومتفائل

:-) وأنا في بعض الأحيان كبير في السن ، مرهق وساخر. دعنا نذهب مع فلسفتك ، يبدو أفضل بكثير :-)

قطعا! هذا هو 80 ٪ من سبب وضع # 5051 في المقدمة - أعتزم سداد الكثير من الديون الفنية التي تراكمت لدينا في منطق البناء الخاص بنا حتى يصبح من الأسهل إعادة استخدامه (كل؟).

باهر!

من IRC الآن :

[sumanah] pradyunsg: هل هناك أي شيء يمكننا فعله لمجتمع الأنابيب والتعبئة والتغليف لمساعدتك في إنجاز المزيد من العمل بشكل أسرع على وحدة الحل؟
....
[pradyunsg] في الواقع ، في الوقت الحالي ، من المحتمل أن تساعدني المدخلات على https://github.com/pypa/pip/issues/6536 في معرفة كيفية التعامل مع العمل / الحصول على تعليقات من الأشخاص وما إلى ذلك.
....
[sumanah] pradyunsg: re: New Resolver: Rollout، Feedback Loops and Development Flow # 6536 - المدخلات التي تريدها هي شيء مثل: هل نهج علم الميزة فكرة جيدة؟ هل من الجيد الحصول على تعليقات عبر آلية أخرى غير مشكلات pip GitHub؟ هل من الجيد الحصول على منحة أو ما شابه ذلك للحصول على اختبار يدوي حقيقي في العالم وبناء بنية تحتية قوية للاختبار و / أو اتصالات استباقية؟
...
[pradyunsg] نعم - ما إذا كانت الأفكار التي أقترحها جيدة. وأيضًا ، ستكون أي أفكار / مناهج / أفكار إضافية قد تساعد في طرح التطبيق + التعليقات بشكل أكثر سلاسة أمرًا رائعًا.

لذا:

هل نهج علم الميزة فكرة جيدة؟ نعم.

هل من الجيد الحصول على تعليقات عبر آلية أخرى غير مشكلات Pip GitHub؟ نعم. يجب أن نجد طرقًا آلية لقبول تقارير الأخطاء الأقل تنظيمًا من المستخدمين الأقل خبرة.

هل ستساعد البنية التحتية للاختبار الأكثر قوة؟ نعم ، كثيرًا ، وهذا مكان قد يتمكن رعاتنا من مساعدتنا فيه.

هل يمكن أن تساعد شركة Changeset (me) ، بموجب العقد الحالي مع PSF للمساعدة في تنسيق / اتصالات PyPA ، في الحصول على اتصالات استباقية لتزويدنا باختبار يدوي أكثر انتظامًا في العالم الحقيقي؟ على افتراض أن لديّ ساعات متبقية في عقدي بحلول الوقت الذي نريد أن نبدأ فيه هذا الطرح ، نعم.

هل هي فكرة جيدة الحصول على منحة أو ما شابه ذلك للحصول على مزيد من المساعدة في تجربة المستخدم والاتصالات / الدعاية والاختبار؟ نعم. من المحتمل أن تكون منح PSF ذات أهمية ، كما هو الحال بالنسبة لمنح NLNet (للطلبات التي تقل عن 30000 يورو ) ، ومن المحتمل أن يكون برنامج Chan Zuckerberg الأساسي مفتوح المصدر لمنحة العلوم ، و Mozilla MOSS . يمكن أن تكون مجموعة عمل التعبئة والتغليف هي مقدم الطلب للتسجيل. إذا أرادpradyunsg أو pfmoore إعطاء إيماءة "نعم هذا يبدو مثيرًا للاهتمام" ، يمكنني البدء في التحقيق في هذه الاحتمالات مع مجموعة العمل.

إذا أرادpradyunsg أو pfmoore إيماءة "نعم هذا يبدو مثيرًا للاهتمام" ،

بالتأكيد يبدو مثيرًا للاهتمام بالنسبة لي :-)

يريد pradyunsg أو pfmoore إعطاء إيماءة "نعم هذا يبدو مثيرًا للاهتمام"

_nods_ نعم هذا يبدو مثيرًا للاهتمام

هل ستساعد البنية التحتية للاختبار الأكثر قوة؟ نعم ، كثيرًا ، وهذا مكان قد يتمكن رعاتنا من مساعدتنا فيه.

brainwane أيضًا ذو صلة هنا https://github.com/pypa/integration-test. أعتقد أن الحصول على هذا الإعداد هو مجال محتمل آخر للتمويل - يجب أن نضيف هذا إلى https://wiki.python.org/psf/Fundable٪20Packaging٪20Improvements.

موافق! لقد بدأت التحدث مع PSF ومع أفراد مبادرة Chan Zuckerberg حول التقدم بطلب للحصول على منحة CZI عبر مجموعة عمل التعبئة والتغليف. لقد أضفت بعض التفاصيل إلى صفحة تحسينات التعبئة القابلة للتمويل حول سبب أهمية محلل النقطة الجديد ، وأضفت مشروع integration-test إلى تلك القائمة. وقد بدأت في جمع أسماء خبراء تجربة المستخدم الذين لديهم القدرة على البحث في سلسلة أدوات توزيع / تثبيت حزم سطر الأوامر المعقدة ، والتحدث مع المستخدمين لفهم نموذجهم العقلي لما يحدث وما يجب أن يحدث ، ونصح المشرفين.

إذا حصلنا على أموال عبر منح من MOSS أو CZI أو NLNET ، أعتقد أننا سنحصل على المال ... أكتوبر في أقرب وقت ممكن ، على الأرجح. قد تكون المنحة المباشرة من PSF أسرع على الأرجح ولكن "تركيزنا الحالي هو ورش عمل ومؤتمرات لغة Python (خاصة للمساعدة المالية) وجهود التنوع / الشمولية في Python."

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

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

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

آسف للقفز ، سعيد لرؤية هذا المضي قدما!

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

كواحد من الأشخاص الذين تعرضوا للعض من بعض مشكلات PEP 517 لهذا السبب بالذات ، أود حقًا أن أرى طريقة اختيار لاختبار الأشياء. لكنني أعرف فقط عن هذه الأشياء كيندا لأنني اشتركت في جميع مصادر أخبار تغليف Python التي يمكنني الحصول عليها بعد مشكلة العلم --no-use-pep517 . ما أقوله هو أن نشر هذا النوع من الأخبار أمر صعب وربما يكون السبب وراء صعوبة الحصول على التعليقات.

أعتقد أن المزيد من الناس سيكونون مهتمين بهذا إذا أمكن نشر المعلومات بشكل أفضل. هل هذا ما ستسمح به الموارد التي تبحث عنها؟

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

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

الشيء الأساسي هو أن هذا الإعداد يحتاج إلى التعلم عنه وإنجازه - مرة واحدة فقط - بدلاً من الاضطرار إلى التعرف باستمرار على علامات الميزات الفردية الجديدة أو تعديل إعدادات CI أو اختبارها يدويًا.

ومع ذلك ، فإن الأمر الذي قد يبدو أكثر قابلية للتنفيذ هو وجود علامة _ واحدة_ لميزة يجب معرفتها ،

بمعنى ما ، ألا يوجد هذا بالفعل في شكل --pre ؟ هل يمكن أن تكون قناة الإصدار التجريبي للنقطة مجرد مسألة تشغيل pip install --upgrade --pre pip ؟

آسف للقفز ، سعيد لرؤية هذا المضي قدما!

techalchemy من فضلك ، من بين جميع الأشخاص ، لا داعي لأن تشعر بالأسف بالتأكيد على الترويج في هذه المناقشة.

هل هذا ما ستسمح به الموارد التي تبحث عنها؟

إلى حد ما ، نعم.

reg: إصدارات بيتا / "قناة" للنقطة

شكرًا على الرنين في jriddy و @ chrish42. على الرغم من أنني أعتقد أنه من المؤكد أن هذه محادثة مفيدة / مهمة يجب إجراؤها ، إلا أنني أشعر أيضًا أنه من المهم جدًا إجراء هذه المحادثة بشكل طفيف. لا أقل ، سأرد هنا مرة واحدة ؛ إذا أردنا مناقشة هذا الأمر أكثر ، فلنفتح مشكلة جديدة.

لقد جربنا ذلك في الماضي - مؤخرًا مع النقطة 10 - لكنها لم تنجح بشكل جيد. أنا متشكك قليلاً في مدى نجاح ذلك في المضي قدمًا أيضًا ، لكن يمكنني أيضًا أن أتخيل أن بعض التغييرات في عمليتنا قد تؤدي إلى هذا العمل بسلاسة بالنسبة لنا. ربما يمكننا عمل مجموعة "تجريبية فقط" من الميزات أو شيء من هذا القبيل؟ كنت أتخيل أن -X all هو بناء جملة لذلك في # 5727. ربما يمكننا اختيار ذلك كجزء من خطة الطرح هذه؟ لا أعلم. سنحتاج إلى استثمار الوقت والطاقة لمعرفة ذلك. :)

كما هو مذكور في https://github.com/pypa/packaging-problems/issues/25#issuecomment -520167480 ، أعتقد أنه من المهم أن يكون لديك شرح موحد لكيفية تغيير الحلول لتجربة النقطة. سيصاب الكثير من الناس بالإحباط بسبب التحول إلى نظام أكثر صرامة (على الرغم من أن الأمور يجب أن تكون أكثر موثوقية بشكل عام ، فسوف يتم حظرهم في الأماكن التي لا يتم حظرهم فيها حاليًا.

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

الإصدار التجريبي فكرة جيدة. في كوندا ، لدينا قناة تجريبية ، كوندا كناري. نحن نشجع الناس على إنشاء وظيفة CI للتنافس ضد الكناري بطريقة تساعدهم على معرفة ما إذا كانت تغييرات Conda ستؤدي إلى كسرهم. من الناحية المثالية ، أبلغونا قبل إصدار هذا الإصدار. كانت تلك القناة فشلاً ذريعًا للغاية. المرة الوحيدة التي يبدو أن الناس يستخدمونها حقًا هي عندما يريدون الحصول على أحدث إصدار لإصلاح بعض الأخطاء التي يعانون منها. لا نحصل على العديد من التقارير من المستخدمين الأوائل المقصودين. ما زلت أعتقد أن الإصدار التجريبي فكرة جيدة ، لأنه عندما يسير الإصدار بشكل سيئ ويغضب الناس منك لكسر 700 عقدة مُدارة ، يمكنك أن تقول "حسنًا ، لقد كان متاحًا لمدة أسبوع قبل أن نطلقه. لماذا لا هل تختبر هذه الأشياء قبل طرحها على 700 عقدة؟ " أنت تمنح الناس فرصة لجعل الأشياء تعمل بشكل أفضل. ساعدهم على إدراك أن تجاوز هذه الفرصة يعني المزيد من الألم لهم في المستقبل. إنه استثمار يستحق العناء بالنسبة لهم ، وإذا فعلوا ذلك كجزء من CI الخاص بهم ، فلن يكلفهم ذلك أي وقت بعيدًا عن الإعداد.

فيما يتعلق بالعلم: أعتقد أنه من الأفضل أن يكون لديك خيار تكوين (ربما بالإضافة إلى علامة). لا أريد أن أمرر راية طوال الوقت. لست متأكدًا مما إذا كانت النقطة تتمتع بهذه القدرة - فربما تخبر الأشخاص الذين يريدون تبديلًا دائمًا أن يستخدموا var المطابق؟

بخصوص العلم:

خيارات CLI الخاصة بـ pip ، يتم تعيينها تلقائيًا إلى خيار ملف التكوين ومتغير البيئة ، مع الأسماء المناسبة.

msarahan شكرا على الرنين في ، أقدر كثيرا! :)

فيما يتعلق بخيار "دعني أفعل ما أريد" لتجاهل التبعيات المعطلة ، أعتقد أنه سيكون من المرغوب فيه هيكلة علامة الميزة بحيث يمكن أيضًا أن تكون بمثابة إلغاء الاشتراك بعد تشغيل المحلل افتراضيًا (على سبيل المثال ، ابدأ باستخدام --avoid-conflicts كمشترك ، انتقل في النهاية إلى --no-avoid-conflicts كإلغاء الاشتراك ، لكن اقبل كلا الخيارين من البداية)

ستحتاج أيضًا إلى التفكير في كيفية تفاعل --ignore-installed مع المحلل - عندما يتم تمريره ، من المحتمل أن تتجاهل جميع متطلبات الحزم المثبتة بالفعل.

علاوة على ذلك ، فإن التعامل مع الأشياء على أنها تصحيحات إعادة بناء أصغر لتسهيل تكامل المحلل هو طريقة ممتازة للذهاب (هذا هو النهج الذي جعل واجهة برمجة تطبيقات التكوين الجديدة لـ CPython ممكنة: الكثير من عمليات إعادة البناء الخاصة التي كانت في النهاية مستقرة بدرجة كافية لإتاحتها للعامة)

ncoghlan ماذا يعني "الانسحاب" من وحدة الحل؟ تجنب دقة التبعية تمامًا (ومن ثم المحلل) هو --no-deps . أفهم أن هناك حاجة إلى "تجاهل تعارضات الإصدار على هذه الحزمة" أو شيء من هذا القبيل.

أنا شخصياً لا أرى أي فائدة من الاحتفاظ بمنطق حل "الاحتفاظ بالاطلاع أولاً" لفترة أطول من فترة انتقالية إلى محلل جديد.

ومع ذلك ، إذا كانت هناك حالات استخدام لا يغطيها هذان الخياران ، أود حقًا أن أعرف عنها. :)

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

أنا شخصياً لا أرى أي فائدة من الاحتفاظ بمنطق حل "الاحتفاظ بالاطلاع أولاً" لفترة أطول من فترة انتقالية إلى محلل جديد.

IDK ، أستخدم هذه "الميزة" للقيام ببعض الأشياء المجنونة جدًا باستخدام البنيات ، مثل ...

# install just the packages I've built specifically
pip install --no-index --no-deps --find-links=/path/to/my/local/build/cache -r local-reqs.txt

# ...snip to later in a dockerfile, etc...

# install the deps from public PyPI
pip install -r local-reqs.txt

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

ولكن ربما لا يزال لسلوك "القرار الساذج" فائدة.

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

من المستخدم النهائي POV ، أوافق على أنه قد تكون هناك سيناريوهات غريبة حيث قد لا يقوم المحلل الجديد بالشيء الصحيح. كما أن وجود علامة طارئة "تعيدني إلى السلوك القديم" يعد آلية انتقال مهمة (على الرغم من أنه يمكن الجدال فيما إذا كان "الرجوع مؤقتًا إلى الإصدار السابق من النقطة" ليس جيدًا - على الرغم من أن أشياء مثل الاستخدام الشائع لـ CI يستخدم تلقائيًا أحدث نقطة مما يجعل الدعوة إلى هذا الخيار إشكالية). لكن على المدى الطويل ، لماذا نحتاج للاحتفاظ بالسلوك الحالي؟ يمكنني تخيل المواقف الرئيسية التالية:

1. علة محلل. احتمال واضح وإصلاح سهل - تصحيح الخطأ في الإصدار التالي من النقطة.
2. الحالات التي يكون فيها المحلل القديم خاطئًا (يولد نتائج تفشل في تلبية القيود). لا ننوي دعم ذلك في المستقبل ، بالتأكيد؟ (على الأقل ليس عن طريق أي شيء أقل تطرفًا من قيام المستخدم بتثبيت ما يريد واستخدام --no-deps لإيقاف تشغيل وحدة الحل).
3. الحالات التي يعطي فيها المحللان القديم والجديد نتائج مختلفة ، وكلاهما يفي بالقيود المحددة. يمكن للمستخدمين إضافة قيود لفرض النتيجة القديمة (إذا لم يتمكنوا من ذلك ، فهذا يعيدنا إلى (2)). يجب أن نمنحهم الوقت للقيام بذلك ، ولكن بعد ذلك نتخلص من المحلل القديم ، تمامًا مثل أي وظيفة أخرى مهملة.
4. حالة متطرفة نعتبرها معقدة / غريبة جدًا بحيث يتعذر دعمها. هذا يشبه (3) ، لكننا لا نؤكد أن المحلل الجديد يعطي النتيجة "الصحيحة". لا يزال بإمكان المستخدمين تعديل القيود لتجنب الحالة الغريبة ، أو تثبيت واستخدام --no-deps . ولكن في النهاية ، نقول "لا تفعل ذلك" ، وإذا تجاهل المستخدمون هذه الرسالة ، فسنزيل مرة أخرى في مرحلة ما المحلل القديم الذي يقول "لقد حذرناك".

هل هناك أي آخرون فاتني؟ على وجه الخصوص ، في أي مكان يكون فيه إهمال وحدة الحل القديمة ثم إزالتها غير ممكن؟

بالمناسبة ، ما هو أفضل مكان لنشر سيناريوهات "هذه حالة مميزة فكرت فيها" ، حتى لا تضيع؟ أعتقد أنه سيكون من المفيد جمع أكبر عدد ممكن من المواقف الغريبة مسبقًا ، إذا كان ذلك فقط حتى نتمكن من البدء مبكرًا في كتابة حالات الاختبار :-)

ملاحظة: ربما يتعين علينا أيضًا ، كجزء من العمل التحضيري للمحلل الجديد ، مسح مشاكل القيود "النموذجية" (استنادًا إلى ما يوجد في PyPI). من ناحيتي ، من النادر جدًا أن يكون لدي أي شيء أكثر تعقيدًا من "تثبيت النقطة"سيكون من العار أن نتورط في القضايا المعقدة لدرجة أننا نغفل عن الغالبية العظمى من القضايا البسيطة.

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

2. البيانات الوصفية خاطئة. ليست مشكلة كبيرة اليوم ، ولكن من السهل تخيل الحالات التي يجب حلها ولكنها ليست كذلك. تعد البيانات الوصفية لـ PyPI في شكل أسوأ من البيانات الوصفية لـ conda / conda-forge ، وهي بالفعل مشكلة لـ conda. إذا كان هذا خطأ ولا يمكنني الحصول على حل كمستخدم ، فأنا أرغب في إلغاء الاشتراك.

rgommers بالنسبة لـ 6 ، يمكن أن يعمل خيار النمط "تجاهل تعارضات الإصدار في هذه الحزمة" ، أليس كذلك؟

شكرًا ، rgommers - هذه نقاط جيدة.

المحلل بطيء جدًا ، سأعتبر خطأ في المحلل. إذا لم يكن بإمكانه تقديم نتائج أداء كافية في الحالات البسيطة ، فهذا غير مناسب للغرض من وجهة نظري. من ناحية أخرى ، إذا كان لديك شبكة قيود معقدة بشكل كبير تستغرق وقتًا أطول باستخدام محلل كامل (أتمنى أن تكون 20 دقيقة مبالغة ، لا أعتبر ذلك مقبولًا تحت أي ظرف من الظروف!) ، فإننا ندخل في "أشياء نحن تعتبر معقدة للغاية لدعم "الأراضي. بعبارة أخرى ، هل حاول أي شخص أن يطلب من Conda توفير محلل "سريع وقذر" غير دقيق ولكنه سريع؟ إذا لم يفعلوا ذلك (وأنا متأكد من أنهم لن يفعلوا ذلك) فلماذا من المعقول أن نتوقع النقطة؟

من المؤكد أن البيانات الوصفية السيئة هي شيء أعتبره "لن ندعم ذلك" (تذكر ، أنا أتحدث عن "بعد فترة إهمال" هنا!). إن منح المستخدمين الوقت لإصلاح البيانات الوصفية ، وتوفير خيار جملة الهروب "تجاهل تعارض الإصدار على الحزمة X" كافٍ من IMO ، لا ينبغي أن نتوقع الاحتفاظ بجميع الآلات القديمة لمجرد أن بعض الأشخاص لن يقوموا بإصلاح البيانات الوصفية الخاصة بهم.

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

أطلب منه حل تبعياتي بعد أن قمت بتثبيت بعض الحزم المحددة مسبقًا من غرفة قيادة محلية.

jriddy ستعمل إستراتيجية الحل الخاصة بـ "استخدام التثبيت الحالي إذا كان متوافقًا" من أجل ذلك.

ما هو أفضل مكان لنشر سيناريوهات "هذه حالة مميزة فكرت فيها" ، حتى لا تضيع؟

https://github.com/pradyunsg/zazo/

بالنسبة لـ 6 ، يمكن أن يعمل خيار النمط "تجاهل تعارضات الإصدار على هذه الحزمة" ، أليس كذلك؟

نعم ، هذا يبدو وكأنه الخيار الصحيح

(آمل أن تكون 20 دقيقة من المبالغة ، وأنا لا أعتبر ذلك مقبولًا تحت أي ظرف من الظروف!) ، ثم ندخل في منطقة "أشياء نعتبرها معقدة للغاية ولا ندعمها". بعبارة أخرى ، هل حاول أي شخص أن يطلب من Conda توفير محلل "سريع وقذر" غير دقيق ولكنه سريع؟ إذا لم يفعلوا ذلك (وأنا متأكد من أنهم لن يفعلوا ذلك) فلماذا من المعقول أن نتوقع النقطة؟

هناك الكثير من الأشخاص الذين يشكون من أداء conda ، وهم يستمعون - لكن هناك الكثير من العمل ، انظر منشوراتهم الأخيرة في المدونة. لا أعرف ما إذا كان سيكون هناك خيار كوندا سريع وقذر. ومع ذلك ، هناك حلول ذات صلة (اختراق) مثل conda-metachannel والتي تتيح لك تقليم الرسم البياني للتبعية (تضمين / استبعاد الحزم يدويًا) للحصول على حل بشكل أسرع. لذلك أعتقد أن هذا على نفس المنوال.

ومع ذلك ، ضع في اعتبارك أن هذا سيكون مطلوبًا _ بلا حدود_ إلا إذا كنت:

• قم بعمل أفضل بكثير من conda على الفور (ليس من المحتمل جدًا ، ليس الأمر كما لو أن هؤلاء الرجال لا يعرفون ماذا يفعلون - إنها مجرد مشكلة مشعر حقًا).
• لديك مشاكل أصغر لحلها (نأمل أن يكون هذا غير صحيح ، PyPI كبيرة ومع بيانات وصفية جيدة يجب أن تكون المشاكل كبيرة)

البيانات الوصفية السيئة هي بالتأكيد شيء أعتبره "لن ندعم ذلك"

عادل بما يكفي. الموقف برمته من "نحن لا نفرض البيانات الوصفية الصحيحة" لا يساعد هنا بالرغم من ذلك. إلا إذا تغير ذلك مؤخرًا؟ (وأنا أعلم ، إنه شيء PyPI وليس شيئًا Pip - لكنه مرتبط).

لست متأكدًا من أن لديك بالفعل الخيارات التي تعتقد أنك تمتلكها.

ما الذي يفعله المحلل السريع والقذر بشكل مختلف عن المحلل الدقيق؟ ماذا يسقط ليكون أسرع؟ القيود هي قيود - فهي لا تأتي في درجات. إما أن ترضيهم أو لا ترضيه. ربما يمكنك إرضائهم بالاسم فقط للبدء ، ثم بالإصدار ، إلخ.

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

تكمن المشكلة في عقلية "إدخال القمامة ، وإخراج القمامة" في أنه بصفتك مشرفًا على الحل ، فأنت تمسك بالحقيبة. ما لم يكن لديك استدلال جيد جدًا لما هو القمامة ، فأنت عاجز. ينتهي بك الأمر إلى أن تكون الشخص الذي يتعين عليه التحقيق في سبب بطء الحل ، وعزل حزمة المشكلة ، ثم اطلب من مصدر المشكلة إصلاح الأشياء. إنه ليس مكانًا رائعًا أن تكون فيه ، صدقني. نقضي الكثير من الوقت في محاولة شرح سبب استغراق conda إلى الأبد أو عدم عمله مع مزيج من قنوات conda-Forge أو bioconda أو قنوات أخرى تابعة لجهات خارجية. ينتهي بنا الأمر إلى القيام بعمل المباحث وإخبار قنوات الطرف الثالث بما يحتاجون إلى إصلاحه. تمتص.

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

اكتشفwolfv مؤخرًا استخدام libsolv للكوندا. لقد شعر بالإحباط في النهاية لأنه لم يستطع الحصول على نفس إجابات كوندا. يتلخص هذا الاختلاف بين الأساليب. Libsolv هو حل للتراجع. قد يكون بمثابة إضافة اختيارية مجمعة للنقطة لتسريع الأمور ، على الرغم من أنني أعلم أنك حساس لعدم تضمين الكود المترجم مباشرة مع النقطة.

(نشر pradyunsg للتو تحديثه لشهر أغسطس على مدونته .)

بعض الأسئلة والاحتياجات التي يطرحها الأشخاص الآن هي أشياء نحتاج إلى جمعها الآن ، مثل حالات الاختبار.

ولكن أيضًا: ما هو الجدول الزمني الذي نعتقد أنه واقعي لهذا الطرح؟ يعتمد هذا كثيرًا على صحة Pradyun ووقت فراغه ، وتوافر مراجعة الكود من مشرفين آخرين ، وما إذا كنا نحصل على بعض المنح التي نتقدم للحصول عليها ، لكني أعتقد أن التسلسل يشبه:

• بناء إعادة بناء المنطق: قيد التنفيذ ، تم إجراؤه في وقت ما من ديسمبر إلى فبراير
• بحث وتصميم UX ، واختبار بناء البنية التحتية ، والتحدث إلى المصب والمستخدمين حول علامات التكوين والجداول الزمنية للانتقال: نحن بحاجة إلى تمويل لهذا ؛ من المحتمل أن تكون أقرب بداية هي ديسمبر ، وسوف تستغرق 2-3 أشهر
• تقديم التجريدات المحددة في resolvelib/zazo أثناء إجراء اختبار ألفا: سيستغرق الأمر بضعة أشهر ، لذا ، هل التقدير المتحفظ ، مايو 2020؟
• اعتماد قرار تبعية أفضل وإجراء اختبار تجريبي:؟

هل هذا صحيح؟ ماذا ينقصني؟

أسأل لأن بعض أعمال جمع المعلومات هي أشياء يجب على مدير المشروع و / أو باحث UX القيام بها ، في رأيي ، ولأن بعض التقدم على https://github.com/pypa/packaging-problems/issues/264 و قد تساعد المشكلات الأخرى في التعامل مع المخاوف التي أثارها الأشخاص هنا.

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

نظرًا لأن استخدام التبعيات غير المقيدة أو >= some_old_version هو القاعدة وليس الاستثناء لـ setup.py / pyproject.toml ، فستكون هذه مشكلة. لا أهتم حقًا إذا كان "قيدًا غير صحيح" أو إذا كان المحلل بحاجة إلى اتخاذ خيارات مختلفة - فهذه هي حالة البيانات الوصفية في PyPI.

تسببت هذه القيود المفتوحة في استكشاف Conda لحلول سيئة حقًا تتطلب الكثير من التخفيضات.

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

في الواقع ، لست متأكدًا مما إذا كان pip _يمكن أن يؤدي إلى الرجوع إلى إصدار سابق للأشياء. أولاً ، كان لديها استراتيجية "ترقية كل شيء" شديدة العدوانية ، والآن تعمل "الترقية حسب الحاجة" بشكل جيد. لم أره مطلقًا يخفض مستوى أي شيء ، وعمليًا فهو يعمل بشكل جيد للاستخدام المنتظم.

مثال على الرجوع إلى إصدار أقدم يجب أن تتعامل معه Conda ، لكن النقطة لن تفعل ذلك: يبدأ مستخدمو الأناكوندا أو المينيكوندا مع بيثون 3 بيثون 3.7. يحتاج المستخدمون أحيانًا إلى تثبيت شيء متاح فقط لـ python 3.6. يجب أن يخفض المحلل إصدار Python وجميع الحزم الأخرى بخلاف noarch. هذه حالة خاصة يمكن تحسينها من خلال وجود سلوك خاص لتغييرات إصدار Python ، ولكنها توضح مدى الكيفية التي قد تتطلب بها التغييرات في حزمة ما خفض مستوى إلى حزمة أخرى. "لقد نجحت حتى الآن" هو حظ أحمق ، وليس ما ينجح في الواقع طوال الوقت.

بالنسبة لتقييد الإصدارات ، لا يمكنك تطبيق ذلك في الحل نفسه. لديك قيودك ، وأي نوع من "الانفتاح بواسطة إصدار واحد" لا يمكن أن يأمل في أن يكون عامًا بما فيه الكفاية ، لأنه مختلف لكل حزمة. يمكنك قص البيانات الوصفية حسب الإصدار السابق للحل. هذا ما هو "current_repodata.json" لـ conda. فقط أحدث إصدار. إنه يجعل الأشياء تسير بسرعة كبيرة عندما تعمل ، لكن الناس سيصابون بالجنون حقًا إذا كانت هذه هي البيانات الوحيدة. لن تكون الأشياء قابلة للتكرار ، وسيصابون بالإحباط لأن المواصفات التي تعمل يومًا ما قد لا تعمل في اليوم التالي. نحن نقدم احتياطيًا إلى إعادة البيانات الكاملة ، ونخطط أيضًا لتقديم مجموعات فرعية تستند إلى الوقت ، مع توفر أحدث الإصدارات فقط في نقاط معينة في الوقت المناسب. قد يكون فتح بيانات الفهرس المتاحة بشكل متزايد مفهومًا أكثر فائدة مع أداة حل التراجع.

pip _يمكن_ حتى الرجوع إلى إصدار سابق للأشياء.

يمكن - بالنسبة إلى النقطة ، الرجوع إلى إصدار أقدم مجرد خطوة لإزالة التثبيت مثل الترقية. ويتم تقليله عندما يرى أحد القيود التي طُلب منه تلبيته.

يؤدي ما يلي إلى خفض مستوى أدوات الإعداد - طالما أن هذا هو أول شيء تراه النقطة:

pip install "setuptools < 20.0"

ما هو أفضل مكان لنشر سيناريوهات "هذه حالة مميزة فكرت فيها" ، حتى لا تضيع؟

https://github.com/pradyunsg/zazo/

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

مثال على الرجوع إلى إصدار أقدم يجب أن تتعامل معه Conda ، لكن النقطة لن تفعل ذلك: يبدأ مستخدمو الأناكوندا أو المينيكوندا مع بيثون 3 بيثون 3.7. يحتاج المستخدمون أحيانًا إلى تثبيت شيء متاح فقط لـ python 3.6. يجب أن يخفض المحلل إصدار Python وجميع الحزم الأخرى بخلاف noarch. هذه حالة خاصة يمكن تحسينها من خلال وجود سلوك خاص لتغييرات إصدار Python ، ولكنها توضح مدى الكيفية التي قد تتطلب بها التغييرات في حزمة ما خفض مستوى إلى حزمة أخرى. "لقد نجحت حتى الآن" هو حظ أحمق ، وليس ما ينجح في الواقع طوال الوقت.

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

مثال آخر هو عدم الاتساق بين القنوات. المثال الأخير: كنا في Python 3.7.3 ، ثم حصلنا على $ base 3.7.4 . لا أهتم بهذه الاختلافات في الإصدارات ، ولن يهتم بها معظم المستخدمين. قد يكون الخيار الافتراضي "لا تفعل شيئًا" أفضل بكثير من "مرحبًا .4 > .3 ، فلنقم بترقية ذلك ثم نغير قنوات الحزم الأخرى إلى base إذا اضطررنا إلى ذلك (حتى لو أدى ذلك إلى تقليل ذلك)".

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

هذا يبدو وكأنه تحسن مفيد للغاية.

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

نعم هذا صحيح. أعتقد أن كل بيئة تطوير متكاملة أو توزيع أو "واجهة مشتركة لمجموعة من الأشياء" بها هذه المشكلة.

يؤدي ما يلي إلى إرجاع setuptools

هذا هو الرجوع الذي طلبه المستخدم. واحد غير مباشر هو ما قصدته (على سبيل المثال setuptools<20.0 في pyproject.toml`). أعتقد أن هذا سيعمل بشكل جيد ، لكنه نادر في الممارسة.

تكمن المشكلة في عقلية "إدخال القمامة ، وإخراج القمامة" في أنه بصفتك مشرفًا على الحل ، فأنت تمسك بالحقيبة.

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

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

وفي الواقع ، بالنسبة لجزء كبير من حالات الاستخدام ، من المرجح أن تعطي أدوات الحل القديمة والجديدة نفس النتائج على أي حال.

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

محاولة استنباط سلوك عاقل لأي خردة قديمة ليست قابلة للتطبيق - علينا أن نرسم خطًا في مكان ما.

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

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

rgommers ، انتقلت conda 4.7 إلى هذا - تتطلب مواصفات python الصريحة لتغيير الإصدارات الثانوية. لقد كره الناس ذلك. ليس لدي أي فكرة عن جزء السكان الذين يتحدثون بصوت عالٍ ، لكن الكثير من الناس لا يحبون حقًا أنهم اعتادوا أن يكونوا قادرين على conda install ما ، والآن لا يمكنهم ذلك. إنهم لا يهتمون كثيرًا بالسبب ، وهم في الغالب يهدئون من الإجابة ، لكننا ما زلنا نتعامل مع العداء في هذه الأثناء. مجرد مثال آخر على

لا يهم "الحق" للمستخدمين عند تعطلهم من التغييرات التي أجريتها.

مثال آخر هو عدم الاتساق بين القنوات. مثال حديث: كنا في Python 3.7.3 ، ثم حصلت القاعدة على 3.7.4. لا أهتم بهذه الاختلافات في الإصدارات ، ولن يهتم بها معظم المستخدمين. سيكون الخيار الافتراضي "لا تفعل شيئًا" أفضل بكثير من "مرحبًا .4> .3 ، دعنا نحدث ذلك ثم نغير قنوات الحزم الأخرى إلى القاعدة إذا كان علينا ذلك (حتى لو كان ذلك يقلل من تلك)".

هذه نقطة أكثر تعقيدًا. أنت تقترح في الأساس معايير تحسين مختلفة. ربما تكون قد شاهدت الخطوات الـ 11 الحالية في منشور المدونة الخاص بنا على https://www.anaconda.com/understanding-and-improving-condas-performance/

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

مرحبًا ، شكرًا msarahan على الإشارة إلي في هذا العدد. كنت أرغب في الرنين في وقت سابق لكني لم أجد الوقت.

في الواقع لقد جربت استخدام libsolv كحل لمواصفات conda. وهو يعمل بالفعل - الاختلاف المتبقي الآن هو أن conda لا تهتم كثيرًا برقم البنية ، ولكن libs حل بالطريقة التي يتم ترميزها بها (ومع حلال التراجع). حتى عند استخدام repodata الكامل ، فإن libsolv سريع حقًا - سأذهب إلى حد القول إن سرعة libsolv سريعة بما يكفي بحيث لا تكون مزعجة :)

كانت مساهمتي الكبيرة في libsolv هي جعله متوافقًا عبر الأنظمة الأساسية بحيث يتم تجميعه الآن على أنظمة التشغيل Windows و OS X و Linux.

أود أن أدعو تمامًا إلى استخدام libsolv لوحدة الحل الجديدة ، على الرغم من أنها كتلة من التعليمات البرمجية المجمعة (على الأقل سريعة) وقد يكون mlschroe متاحًا للمساعدة - لقد ساعد كثيرًا في دعم libsolv لـ كوندا تطابق.

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

ربما تكون قد شاهدت الخطوات الـ 11 الحالية في منشور المدونة الخاص بنا على https://www.anaconda.com/understanding-and-improving-condas-performance/

بالفعل فعلت. كان ذلك منشور مدونة لطيف.

أنت تقترح في الأساس معايير تحسين مختلفة.

ليس حقيقيا. أعتقد أن _ "قيد التوافق الثنائي مقابل قيد الإصدار البسيط والبسيط" _ يشير فقط إلى شيء ما أفتقده على الأرجح. ما أتوقعه هو أنه لا يجب أن تحتوي الحزمة على python >= 3.7.4 أو == 3.7.4 في بياناتها الوصفية ، فهي دائمًا == 3.7 (تم التحقق فقط من scipy ، meta.yaml تقول python و conda_forge.yml تقول max_py_ver: '37' - أمر منطقي). لذا فإن تقديم 3.7.4 لا يجب أن يفعل شيئًا - المحلل الذي يختار 3.7.3 وعدم تغيير أي شيء آخر هو أرخص بكثير (وصالح وفقًا لخطواتك الـ 11) من فرض 3.7.4 وإطلاق سلسلة من أعلى / أسفل الدرجات.

أعتقد أن هذا الجزء أصبح بعيدًا عن الموضوع لخطط طرح pip ، لذا من دواعي سروري أن تأخذ هذا في مكان آخر.

نصيحتي هي قضاء الكثير من الوقت في جعل المحلل قابلاً للتصحيح.

+1

أيضًا: اجعلها قابلة للإصلاح قدر الإمكان (احتفظ بها). هذا هو الشيء الجميل مع pip الآن ، إذا حدث خطأ فعادة ما يمكن للمرء أن يفعل cd site-packages && rm -rf troublesome_package (ربما يتبعه إعادة التثبيت بـ --no-deps ) وتعمل الأشياء مرة أخرى. يصعب إصلاح أمثال conda و apt والأصدقاء بهذه الطريقة.

أنت تقترح في الأساس معايير تحسين مختلفة.

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

لا تحتوي الحزم على python> = 3.7.4 ، ولا == 3.7.4. المعيار في عبوة Conda هو أن يكون لها حد علوي وسفلي. يتم تحديدها تلقائيًا بشكل عام عن طريق conda-build باستخدام المعلومات المقدمة من مؤلف الوصفة فيما يتعلق بعدد أماكن الإصدار التي يجب اعتبارها نطاقًا متوافقًا. تحتوي الحزم على قيود مثل> = 3.7.2 ، <3.8.0a0 ، مع وجود إحراج 0a0 لمراعاة حقيقة أن الإصدارات التجريبية أقل من 0. نتوقع ذلك حقًا.

تحتوي الحزم أيضًا على قناة مرتبطة بها. تعد هذه القناة جزءًا فعالًا من تحسين الإصدار: https://github.com/conda/conda/blob/4.6.7/conda/resolve.py#L1074 - تشبه القناة إصدارًا فائقًا ، متقدمًا على القناة بمكان واحد الإصدار الرئيسي للحزمة. إذا كان الحل لا يجب أن يغير لغة python ، فلا يمكن أن تكون مواصفات python == 3.7 - هذا نطاق ، وستؤثر القناة على هذا النطاق. على وجه التحديد ، وجود مواصفات python == 3.7 والبدء بالتثبيت من القناة defaults ، ثم إضافة قناة conda-forge سيؤدي إلى الكثير من التغيير ، لأنك أدخلت حزم Python جديدة هي أعلى في "الإصدار" (بما في ذلك القناة) ، ومواصفات Python الخاصة بك تسمح بهذا التغيير.

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

أيضًا: اجعلها قابلة للإصلاح قدر الإمكان (احتفظ بها). هذا هو الشيء الجميل مع pip الآن ، إذا حدث خطأ ما ، فيمكن للمرء أن يقوم بحزم موقع القرص المضغوط && rm -rf trouble_package (ربما يتبعها إعادة التثبيت باستخدام - no-deps) وستعمل الأشياء مرة أخرى. يصعب إصلاح أمثال Conda و apt والأصدقاء بهذه الطريقة.

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

(libsolv tangent: مرة أخرى عندما كنت أعمل لدى RH ، قمت بإمساك https://pypi.org/project/solv/ لإغلاق ثغرة الأمان "pip install solv" في Fedora ، نظرًا لأن عملية إنشاء libsolv لا تؤدي إلى أرشيف sdist أو wheel في الوقت الحالي ، ناهيك عن نشره على PyPI. سعيد للدردشة مع أي شخص قد يكون مهتمًا بعمل روابط المكتبة الحقيقية هذه بنسخة حزمة من libsolv ، بدلاً من العنصر النائب غير الضار الآن)

فيما يتعلق بتعليقي "إلغاء الاشتراك" ، لا أعني "الرجوع إلى منطق التثبيت القديم" ، أعني "توفير خيار لتخطي حزم التثبيت التي قد تتسبب في انتهاكات القيد ، بدلاً من فشل طلب التثبيت بالكامل".

تقدم Yum / DNF ذلك عبر خيار --skip-broken (في DNF ، هذا العلم هو اسم مستعار لـ --setopt=strict=0 ) ، وأعتقد أن محلل pip يجب أن يقدم خيارًا مشابهًا.

ncoghlan آه صحيح. منطقي.

خيار النمط "تجاهل تعارضات الإصدار على هذه الحزمة"

لقد ذكرت بالفعل أننا سنفعل ذلك ، ولهذا السبب شعرت بالارتباك من تعليقك.

نحن في نفس الصفحة إذن. :)

أجاب ncoghlan على الجدول الزمني الذي أقترحه على Distutils-sig وقال إنه يبدو معقولًا.

pradyunsg - نتطلع إلى التحديث الشهري القادم!

قضيت بعض الوقت في إلقاء نظرة على هذا مرة أخرى ، وقدمت رقم 7317.

أعتقد أننا على وشك كتابة الأفكار التجريدية - بفضل الكثير من العمل على تفاعل مؤشر النقطة ، ودقة التبعية + الفصل المنطقي للبناء ومجموعة من عمليات التنظيف العامة.

لقد أغلقت للتو # 7317. بقدر ما أستطيع أن أقول ، فإن دقة التبعية الآن مفصولة (بشكل كافٍ) عن منطق بناء البيانات الوصفية. لقد أحرز معمل إعادة بناء منطق البناء تقدمًا جيدًا ولم يعد مانعًا لمزيد من التقدم الآن.

يمكننا الآن أن نبدأ العمل على تنفيذ [حل] التجريدات قيد التنفيذ ، مع الأخذ بالإشارة من [passa] ومحلل الشعر حيثما كان ذلك مناسبًا. :)

pradyunsg أخطط لاستخراج المحلل الأساسي (استنادًا إلى PubGrub) من قاعدة كود الشعر (انظر https://github.com/sdispater/poetry/tree/master/poetry/mixology). يتم فصلها في الغالب عن بقية الكود ولكن لا تزال هناك إشارات إلى الأجزاء الداخلية التي أحتاج إلى تجريدها.

إذا كنت مهتمًا بالمساعدة في ذلك ، فيرجى إبلاغي بذلك. الفكرة هي أن يكون لديك تنفيذ مستقل لخوارزمية PubGrub التي يمكن استخدامها من قبل أطراف ثالثة وسيتم وضعها في https://pypi.org/project/mixology/ الذي يحمل حاليًا رمز المحلل القديم.

تضمين التغريدة لا أعرف ما إذا كان بإمكاني المساعدة مباشرة (قيود الوقت) ، لكن سيكون من الرائع أن تفصل منفذ PubGrub عن بقية الشعر!

أحد الأشياء التي ستكون رائعة حقًا ، هو أن يكون لديك طبقة تجريد متسقة ، مثل أن يستخدم Pip والشعر و pipenv نفس التجريدات. في الوقت الحالي ، لدينا zazo (لي) ، و mixology (شعر) و ريسلفليب (pipenv's) - كلها تحدد طبقة تجريدية من نوع ما وهي مختلفة قليلاً ولكنها (يبعث على السخرية!) متشابهة. إذا كنت منفتحًا على هذا ، فأخبرنا بذلك!

لمعلوماتك ، نحن ( wolfv ، وفريق QuantStack بشكل عام) قمنا بالرد على RfP لمحلل تبعية النقطة.

النهج المقترح هو اعتماد مكتبة libsolv C ، والمساهمة في دعم تنسيق قيود إصدار النقطة لـ libsolv. سنكشف عن مكتبة C من خلال روابط Python الجديدة.

Libsolv هي مكتبة محصنة ضد المعارك تقوم على أساس النظام البيئي RPM ، وبالتالي فهي مستخدمة بالفعل على المستوى الصناعي.

• يتم توزيع Libsolv's بموجب ترخيص BSD-3-Clause.
• يدعم Libsolv الحزم المتعددة وتنسيقات المستودعات ، مثل rpm ، deb ،
  haiku ، conda ، arch . الأهم من ذلك ، تنوع الأشكال وطرق التعبير
  تظهر قيود التبعية أنه نظام قابل للتوصيل يجب أن يكون قادرًا
  لاستيعاب صيغة النقطة للقيود المفروضة على إصدارات التبعية ..
• باستخدام libsolv بدلاً من أداة حل conda في غلاف مامبا الرقيق ، كنا كذلك
  قادرة على تحسين أداء Conda بشكل ملحوظ. (كان بطء Conda في دقة الحزمة مع القنوات الكبيرة دافعنا الرئيسي للعمل على mamba).
• يعمل عبر الأنظمة الأساسية على أنظمة التشغيل Windows و OS X و Linux. ( @ wolfv فعل منفذ windows من libsolv)
• يقوم بحل SAT الكامل للعثور على مجموعات التبعية المثلى وإذا لم ينجح ، فإنه يقوم بإرجاع تلميحات قابلة للتنفيذ لحل التعارض.

النهج المقترح هو اعتماد مكتبة libsolv C

يجب أن يكون هناك احتياطي للأنظمة الأساسية التي لا يدعمها libsolv (على سبيل المثال ، يتم العمل بنشاط على دعم AIX في النقطة ، ولم تذكر BSD). إذن libsolv كخيار أداء حيث يكون متاحًا بالنسبة لي ، لكننا لسنا في وضع يسمح لنا باستخدامه فقط . (هل هناك نسخة Python خالصة من libsolve ، أي شيء يعطي نفس النتائج ، ولكن بشكل أبطأ؟)

أيضًا ، كيف سيعمل get-pip.py؟ هل سيتعين علينا تضمين ثنائيات لـ libsolv لجميع الأنظمة الأساسية الممكنة؟ مرة أخرى ، لن أفترض ، سنستخدم احتياطيًا خالصًا من الثعبان.

لقد كان عدم القدرة على استخدام كود C الخارجي مصدر إزعاج للنقطة لفترة طويلة الآن. أرغب في رؤية حل جيد لها ، لكن (أ) لست متأكدًا من وجود حل واحد (أقل من شكل من أشكال حل bootstrapper "mini-pip" الذي يسمح لنا بإلغاء البائع تمامًا) و (ب) إنه عمل كبير بما يكفي لدرجة أنني أكره أن يعتمد المحلل الجديد عليه.

مرحبا pfmoore

أعتقد أن دعم النظام الأساسي الإضافي لا ينبغي أن يكون بهذه الصعوبة لأن libsolv عبارة عن كود C مباشر إلى حد ما. أنا متأكد تمامًا من عدم وجود نسخة بايثون خالصة من libsolv ، رغم ذلك (وهو ما أفهمه هو عيب ، لكن لا يوجد أيضًا إصدار Python خالص من Python ، أو lib القياسي لـ Python ، لذلك في رأيي لا ينبغي أن يكون مانع).

أعتقد أنه من أجل التمهيد ، يمكن للمرء أن يكون لديه نقطة Python خالصة تستخدم الآلية الحالية للحل ، والتي تقوم بعد ذلك بتثبيت محلل lib الضروري بناءً على libsolv. على سبيل المثال ، يمكن للمرء تثبيت الحزمة الدقيقة من روابط Python الخاصة بـ libsolv + pip ، وتثبيتها من Boostrap-pip كما وصفته. يبدو الأمر قابلاً للتنفيذ تمامًا بالنسبة لي ، لكن قد تعرف بشكل أفضل ما الذي سيتضمنه ...

أعتقد أن دعم النظام الأساسي الإضافي لا ينبغي أن يكون بهذه الصعوبة

لكي أكون واضحًا ، ليس لدي اهتمام كبير بالمنصات الأكثر تخصصًا ، أعتقد فقط أنه يتعين علينا أن نكون واضحين جدًا إذا كنا نؤثر على ما يتم دعم نقطة الأنظمة الأساسية عليه (وهو في الوقت الحالي "أي شيء يمكنه تشغيل Python") ). هناك أيضًا سؤال نشر حول كيفية شحن امتداد C (حيث يتم شحن النقطة حاليًا كعجلة "عالمية" ، وهذا مهم لبعض حالات الاستخدام مثل get-pip.py )

أعتقد أنه من أجل التمهيد ، يمكن للمرء أن يكون لديه نقطة بايثون خالصة تستخدم الآلية الحالية للحل

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

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

من المحتمل أن تكون المناقشة مناسبة بشكل أفضل في مكان آخر ، وقد تكون زائدة عن الحاجة تمامًا عند / إذا تم الكشف عن مزيد من التفاصيل ، لكنني أريد حقًا ترك أسئلتي الآن.

من فهمي ، يستخدم libsolv محلل SAT كاملًا لحل التبعية ، ويتطلب تحميل معلومات التبعية أولاً قبل أن يبدأ في الحل. لكن PyPI يخزن الآن بيانات تعريف التبعية لكل حزمة. حتى إذا تجاهلت طبيعة setup.py المعتمدة على وقت التشغيل ، فسيكون من الصعب جلب المعلومات اللازمة لحل SAT بكفاءة.

كيف تخطط للتعامل مع هذه المشكلة؟ هل تخطط لتنفيذ البنية التحتية (واقتراح مواصفات إضافية لعمليات تنفيذ إعادة الشراء التابعة لجهات خارجية) لإنشاء ملفات .solv عند تحميل الحزم؟ أو هل لديك بعض العوائق في سواعدك لتوليد بيانات مناسبة قابلة للحل كما يذهب الحل ، وربما تقوم بتنفيذ بعض التراجع عندما تأتي بيانات التبعية الجديدة؟

لست على علم بأي عمل موجود في هذا الصدد ، ومعظم الموارد التي يمكنني العثور عليها تشير إلى أن مشهد تعبئة Python يحتاج إلى شيء آخر / أكثر من مجرد محلل SAT مباشر. لذلك أنا مهتم جدًا بأي احتمالات هنا.

ملفات .solv هذه مخصصة فقط للتخزين المؤقت ، ولا يحتاجها libsolv لحلها. لكنني أوافق على أن الطبيعة الديناميكية لتبعيات PyPI تجعل من الصعب استخدام محلل SAT.

(راجع https://docs.google.com/document/d/1x_VrNtXCup75qA3glDd2fQOB2TakldwjKZ6pXaAjAfg/edit لمزيد من المعلومات)

(لاحظ أن محلل SAT هو مجرد وسيلة لحل التراجع الذي يتعلم أيضًا في حالة حدوث تعارض ، لذلك أعتقد أنه من الممكن استخدام محلل SAT لـ PyPI. ولكن يجب أن يكون محللًا يسمح بإضافة الجمل ديناميكيًا أثناء الحل.)

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

أنا في المطار الآن لذا لا يمكنني الرد على النقاط التي أثيرت الآن ولكن ... أنا متأكد من أننا لا ينبغي أن نناقش الخيارات / المقايضات الفنية هنا - هذا أكثر تحديدًا كيف نتواصل وندير عملية الطرح مقابل ما نطرحه. :)

لقد قدمت # 7406 لمزيد من المناقشة حول المقايضات الفنية -sdispater ، techalchemy ، uranusjr ، wolfv سأكون ممتنًا إذا كان بإمكاننا إجراء مزيد من المناقشة حول الخيارات المختلفة لتصميم المحلل.

لتحديد التوقعات مبكرًا ، سأسافر خلال الأسبوعين المقبلين ، وآمل أن أتمكن من متابعة كل المناقشات يوم 9 ديسمبر تقريبًا.

تحديث الحالة: تمكنت PSF من الحصول على بعض التمويل من Mozilla Open Source Support ومبادرة Chan Zuckerberg لتوظيف متعاقدين للعمل على محلل النقاط ومشكلات تجربة المستخدم ذات الصلة . يمكنك الاطلاع على خارطة الطريق (التي أحتاج إلى تحسينها) والمدونة والمنتدى ومشاركات القائمة البريدية والملاحظات من الاجتماعات الأخيرة لتبقى على اطلاع. سأقوم بنشر شيء حول هذا قريبًا على distutils-sig ومنتدى التعبئة والتغليف في مثال خطاب Python .

نهدف إلى تجهيز ميزة محلل النقطة للإصدار في النقطة 20.2 في يوليو. (وفقًا لإيقاع الإصدار ربع السنوي للنقطة ، قد تتأخر الصعوبات غير المتوقعة حتى 20.3 في الربع التالي.)

uranusjr :

من فهمي ، يستخدم libsolv محلل SAT كاملًا لحل التبعية ، ويتطلب تحميل معلومات التبعية أولاً قبل أن يبدأ في الحل. لكن PyPI يخزن الآن بيانات تعريف التبعية لكل حزمة. حتى إذا تجاهلت الطبيعة المعتمدة على وقت تشغيل setup.py ، فسيكون من الصعب إحضار المعلومات اللازمة لحل SAT بكفاءة.

يستخدم النموذج الأولي pip resolve أمر في # 7819 طريقتين للحصول على هذه المعلومات بشكل فعال (راجع هذه المشكلة للحصول على التفاصيل):

1. > استخراج محتويات ملف METADATA من عنوان url لعجلة دون تنزيل العجلة فعليًا على الإطلاق.
2. > التخزين المؤقت لنتيجة كل استدعاء self._resolve_one () في ملف json دائم.

التقنية المستخدمة لـ (1) قادرة على تحويل عنوان URL للعجلة إلى قائمة من سلاسل المتطلبات التي يعتمد عليها بسرعة كبيرة ، بينما يتم تنزيل عدد قليل من كيلو بايت فقط من محتويات العجلة نفسها. يضمن النموذج الأولي في # 7819 أن يتم استدعاء req.populate_link() لكل من المتطلبات التابعة التي يتم إرجاعها بواسطة self._resolve_one() ، ويخزن تعيين (==Requirement, url) -> [list of (==Requirement, url) non-transitive dependencies] في ملف تخزين مؤقت json دائم. (1) الحصول على المعلومات الجديدة بسرعة ، (2) يجعل الاستعلام عن المعلومات القديمة سريعًا.

على الرغم من أنني لست على دراية بـ libsolv ، أعتقد أن إدخالات هذا التعيين من عنوان URL للمتطلبات إلى التبعيات وعناوين URL الخاصة بهم قد تكون بالضبط الإدخال الذري المطلوب بواسطة محلل SAT. كما هو موضح في # 7189 ، تسبب ملف ذاكرة التخزين المؤقت لتبعية json الدائمة في أن تصبح استدعاءات pip resolve عمليات استدعاء كاملة بعد التشغيل الأول ، مع أخذ 800-900 مللي ثانية في سطر الأوامر من ذلك الحين فصاعدًا. إذا تم استخدام التقنيات من (1) و (2) ، أعتقد أنه قد يكون من الممكن السماح لمحلل SAT بالعمل حتى الاكتمال في كل مرة يتم فيها استدعاء النقطة دون الانتظار لفترة طويلة بشكل لا يصدق. ربما لن يكون من الصعب للغاية محاولة اختراق libsolv أعلى النموذج الأولي في # 7189 لجعل هذا الرقم أكثر واقعية.

techalchemy :

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

كانت السراويل تحتوي على بعض التعليمات البرمجية التي سهلت كشف مترجم ورابط إلى مشروع قائم على setup.py (# 6273) ، لكننا أزلنا هذا لاحقًا (انظر # 7016) لصالح جعل من الممكن إنشاء C / C ++ في السراويل بدون استخدام setup.py ، والذي كان مناسبًا لحالة الاستخدام الخاصة بنا داخل Twitter والتي تحتاج فقط إلى إنشاء مكتبة مشتركة لمشغلي TensorFlow المخصصين . نستضيف ثنائيات مُنشأة مسبقًا لأرشيفات GCC و binutils المرتبطة بشكل ثابت على s3 الخاص بنا لـ OSX و Linux (راجع https://github.com/pantsbuild/binaries/) حتى لا يضطر مستخدمو السراويل إلى تثبيت أي شيء إلى جانب python و JDK لاستخدام السراويل على الإطلاق.

سأكون مهتمًا بالمساعدة في تبادل الأفكار و / أو تطوير أي نوع من الأدوات لبناء C و C ++ بشكل قابل للنقل والتي قد تمكن النقطة من الاعتماد بشكل موثوق على libsolv على جميع الأنظمة الأساسية المدعومة.

تضمين التغريدة

كانت السراويل تحتوي على بعض التعليمات البرمجية التي سهلت عرض مترجم ورابط لمشروع قائم على setup.py (# 6273) ، لكننا أزلنا هذا لاحقًا (انظر # 7016) لصالح إتاحة إمكانية إنشاء C / C ++ في السراويل دون استخدام setup.py ، والذي كان مناسبًا لحالة الاستخدام الخاصة بنا داخل Twitter والتي كانت بحاجة فقط إلى إنشاء مكتبة مشتركة لمشغلي TensorFlow المخصصين. نحن نستضيف ثنائيات مُنشأة مسبقًا لأرشيفات GCC و binutils المرتبطة بشكل ثابت على s3 الخاص بنا لـ OSX و Linux (انظر Pantsbuild / binaries) حتى لا يضطر مستخدمو السراويل إلى تثبيت أي شيء إلى جانب python و JDK لاستخدام السراويل على الإطلاق.

عمل المترجم / الرابط مثير جدا للاهتمام! هناك أيضًا نقاش حول فصل المترجم عن setup.py (أو PEP 517 build backend بشكل عام). لا يتعلق الأمر حقًا بالمحلل (على الأقل ليس بشكل مباشر) ، ولكن قد تكون مهتمًا: https://discuss.python.org/t/how-do-we-get-out-of-the-business-of- مجمِّعات قيادة سي / 2591

تضمين التغريدة

سأكون مهتمًا بالمساعدة في تبادل الأفكار و / أو تطوير أي نوع من الأدوات لبناء C و C ++ بشكل قابل للنقل والتي قد تمكن النقطة من الاعتماد بشكل موثوق على libsolv على جميع الأنظمة الأساسية المدعومة.

لقد بحثت نفسي و wolfv في هذا لبناء أجزاء من حزمة مدير حزم DNF عبر جميع المنصات الرئيسية المدعومة لـ mamba وعملي الشخصي مع DNF. في هذا الوقت ، أصبح libsolv قادرًا الآن على الإنشاء لنظام التشغيل Windows و Linux و macOS و BSD و Haiku OS ، وأنا على دراية غامضة بوضعه على أنظمة UNIX المختلفة كجزء من استخدام DNF على UNIX. أعلم أن dralley قد أتاح أيضًا عجلات ثنائية solv متاحة لمنصات رئيسية ~ يدعمها PyPI ~ Linux باستخدام manylinux2014 على PyPI .

لدينا الآن نقطة 20.1b1 ، إصدار تجريبي يتضمن إصدارًا مبكرًا جدًا (ألفا) من المحلل الجديد (انظر # 8099 للحصول على سياق حول ذلك ، واستطلاع حيث يمكن للأشخاص تقديم ملاحظات). ها هو الاعلان . و https://github.com/pypa/pip/issues/7951#issuecomment -617851381 يسرد بعض الأماكن التي قمنا بنشر النسخة التجريبية حتى الآن.

النقطة 20.1 خرجت الآن وتتضمن نسخة ألفا من المحلل.

نحن نناقش نشر إصدار آخر للنقطة في مايو ، إصدار يتضمن إصدار ألفا إضافي من المحلل. ونحدد الوقت المناسب لإصدار الإصدار التجريبي من المحلل الجديد وإجراء دفعة "الرجاء اختبار هذا".

واجهنا تأخيرات لأننا كنا نفكر في # 8371 ، وكيفية عرض رسائل خطأ معينة بشكل أفضل ، والتعامل مع مجموعة من الأشياء الأخرى ذات الشعر المشعر ؛ راجع https://github.com/pypa/pip/projects/6 و https://github.com/pypa/pip/projects/5 لمعرفة المزيد عن تقدمنا. # 8206 يناقش الإصدار التجريبي القادم ، النقطة 20.2b2 ، والذي آمل أن نتمكن من نشره بحلول نهاية شهر يونيو.

لقد قمت بنشر تقرير منتصف العام الخاص بنا على مدونة PSF . هناك شيء أساسي يجب معرفته: في وقت لاحق من هذا الشهر ، سنقوم بإصدار النقطة 20.2 والتي سيكون لها إصدار تجريبي من محلل التبعية الجديد (النقطة 20.1 بها إصدار ألفا) متاحًا عبر علامة اختيارية " --use-feature=2020-resolver ". سننشر النقطة 20.2 كثيرًا ونطلب من الكثير من المستخدمين وضع المحلل الجديد في خطواته.

لكل # 8511 قمنا الآن بإصدار النقطة 20.2 . يتضمن هذا الإصدار بيتا من الجيل التالي من محلل التبعية . إنه أكثر صرامة واتساقًا عندما يتلقى تعليمات غير متوافقة ، ويقلل الدعم لأنواع معينة من ملفات القيود ، لذلك قد تنقطع بعض الحلول وسير العمل. يرجى اختباره باستخدام العلم --use-feature=2020-resolver . يرجى الاطلاع على دليلنا حول كيفية الاختبار والترحيل وكيفية الإبلاغ عن المشكلات . يتم إيقاف تشغيل محلل التبعية بشكل افتراضي لأنه ليس جاهزًا للاستخدام اليومي .

نخطط لجعل الإصدار الفصلي التالي للنقطة ، 20.3 ، في أكتوبر 2020. نحن نستعد لتغيير سلوك حل التبعية الافتراضي وجعل المحلل الجديد هو الافتراضي في النقطة 20.3.

يرجى نشر الكلمة بالإشارة إلى منشور المدونة هذا - انشر الكلمة على Hacker News و Reddit و Twitter و Facebook و Dev.to و Telegram وإجابات Stack Overflow ذات الصلة و Slacks و Discords المفضلة لديك. معظم الأشخاص الذين سيؤثر عليهم لا يواكبون أخبار مطور Python المحدد. ساعدهم في الحصول على تنبيه قبل تشرين الأول (أكتوبر) ، وساعدنا في الحصول على تقارير الأخطاء.

(نسخ ملاحظتي من # 988.)

zooba سأل :

هل تعتقد أنه يجب علينا تحديث إصدار النقطة المجمعة مع Python 3.9 في هذه المرحلة (لأول RC)؟

وبالمثل ، هل هناك حاجة لتحديث Python 3.8 لإصداره التالي؟

افترض أنه ، نعم ، بعد إصدار bugfix أوائل الأسبوع المقبل ، نعم ، ولكن pfmoorexavfernandez cjerdonekuranusjrpradyunsg dstufft ما رأيك ؟

آسف ، اضغط على آخر في وقت قريب جدا. منطقتي هي أن تجميع النقطة 20.2 سيجعل الأمر أسهل بكثير على المطورين المتمرسين لاختبار محلل التبعية الجديد بسهولة أثناء اختبار أحدث إصدارات بايثون. لكنني لا أعرف مقدار العمل المطلوب لتحديث هذا الإصدار المجمع ، أو كم مرة تريد القيام بذلك.

وبالمثل هنا ، سيكون من الجيد تضمين 20.2.x في 3.9 لتسهيل الوصول إلى المحلل الجديد.

ما رأيك؟

أنت محق ، هذه هي الخطة. :)

حسنًا ، تمت الإجابة على python-dev - نعم ، يجب تحديث إصدار النقطة المجمعة في Python 3.8 و 3.9 إلى 20.2.x.

بشكل منفصل ، في الدعاية ، سأشير هنا إلى بعض الأعمال قيد التقدم:

خلال الأسابيع 6-8 القادمة ، سأدفع للحصول على دعاية واسعة بحيث يحاول المستخدمون استخدام النقطة الجديدة. أظن أن المشكلة لن تكون كبيرة "لن يتم تثبيت هذه الحزمة الفردية" ؛ ستكون تعارضات غير متوقعة بين حزم معينة ، ربما تعتمد على البيئة وملفات قيود معينة. نحاول الحصول على بعض التعليقات المبكرة من خلال الاستبيان حتى نتمكن بعد ذلك من إصلاح الأخطاء ، وإعداد المزيد من الاختبارات الآلية ، وما إلى ذلك ، وحتى يمكن لهذه الحزم الأولية الحصول على إشعارات ودفع الحزم الثابتة قبل النقطة 20.3 (مثال : مشكلة TensorFlow / numpy / scipy في https://github.com/pypa/pip/issues/8076#issuecomment-666493069).

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

لذلك أخطط للاتصال والاستفادة من المجموعات التي تولي اهتمامًا للزوايا الخاصة بمجال معين - علماء البيانات والمعلمين والفنانين ومتخصصي DevOps وما إلى ذلك.

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

نظرت بالأمس في بعض قوائم الحزم المستخدمة على نطاق واسع وأرسلت بريدًا إلكترونيًا يدويًا إلى عدد قليل من الأشخاص وأنشأت مشكلات في عدد قليل من المستودعات لاقتراح أن يطلبوا من مستخدميهم الاختبار باستخدام الإصدار التجريبي من المحلل الجديد ، لبدء تشغيل الكرة وتجربة بعضها الصياغة / الأساليب للحصول على مزيد من الدعاية والاختبار. أدى ذلك إلى حدوث ارتباك في حالة واحدة على الأقل - راجع https://github.com/sqlalchemy/mako/issues/322#issuecomment-667546739 - وبمجرد إصدار إصدار الخطأ 20.2 ، سأكون أكثر قليلاً منهجية وأوضح عنها

• لماذا نتواصل
• من اخترنا الاتصال به / عندما (سيساعد الربط باستراتيجية وسائل الإعلام العامة)
• لماذا لا يمكننا استخدام الاختبار الآلي للعثور على هذه المشكلات بأنفسنا

لقد حصلنا على القليل من الاهتمام على Twitter ( 1 ، 2 ) و Reddit (أي شخص يريد الرد على هذا السؤال حول تمويل PyPA ؟).

كتب zooba (بخصوص التجميع):

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

أجد أن --use-feature=2020-resolver بالنسبة لي يعمل بشكل عام على إصلاح مشاكل أكثر مما تسببه.

هل فات الأوان لاقتراح طرح أولي عبر:

20.3 الكود الكاذب المقترح

try:
    _2020_resolver()
except:
    legacy_resolver()

مما يعني على الأقل بالنسبة لمشروعاتي أنهم سيمرون جميعًا دون تعديل

بعد ذلك ، بمجرد تعطيل المحلل القديم بشكل افتراضي ، قد يكون لدي بعض المشاريع التي تعمل بموجب محلل 2020 وبعضها ليس ضمن المحلل القديم ، أود أن أكون قادرًا على تعيين علامة واحدة لتمكين الرجوع:

20.4 الكود الكاذب المقترح

try:
    _2020_resolver()
except:
    if not use_legacy_resolver:
        raise
    legacy_resolver()

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

تطوعdi للمساعدة في جمع بعض المتطوعين للمساعدة في الاستجابة الأولى. سيجيب هؤلاء المتطوعون على الأسئلة ويساعدون في تحميل دعم المستخدم بمجرد ظهور النقطة الجديدة - على Twitter و StackOverflow و GitHub - ويصعدون الأخطاء الحقيقية إلى اهتمام المشرف / الفريق المساهم.

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

ها هي خطتي التقريبية:

• ابدأ مناقشة على موقع Discuss.python.org لطلب الدعم
• قم بتوجيه الأشخاص إلى قناة Slack التي يمكن أن تكون بمثابة قناة اتصال بين الجميع
• ابدأ مستندًا يحدد بعض الأسئلة الشائعة واستجاباتنا
• قم بتضمين شجرة قرار للإصدار الجديد -> مشكلة مُقسمة إلى ثلاث مرات
• شارك هذا مع القناة بمجرد أن يكون لدينا تاريخ إصدار معروف
• حاول تحديد موعد المتطوعين تقريبًا ليكونوا متصلين بالإنترنت وفرزهم في الأيام التالية للإصدار

شكرا ياdi. نحن ننتظر حتى الغد للحصول على موافق من المشرفين الآخرين. ونهدف إلى إصدار نقطة 20.3 يوم الأربعاء أو الخميس ، 28 أو 29 أكتوبر.

di أرى أنه تمت الموافقة على خطتك. رجاءا واصل!

di تنبيهًا بشأن التأخير المحتمل في الإصدار .

في حالة عدم تواجدي عندما نتمكن من نشر 20.3 (والذي نأمل أن يكون الأسبوع المقبل) ، فإليك خطة الدعاية .

كما ناقشت في تعليق في مكان آخر ، قررنا تأجيل الإصدار قليلاً ، بسبب ظهور بعض مشاكل CI وبسبب بعض العوامل الخارجية.

في اجتماع الفريق اليوم ، اتفقنا على أن الإصدار 20.3 سيكون على الأرجح غدًا أو الجمعة. يمكنك متابعة # 8936 للمزيد.

لم أفعل الكثير من التوعية لكل حزمة كما اقترحت في تعليق سابق. لكن هذا لا يعني أننا لم نتواصل. بعض أنشطة التوعية التي قمنا بها (بعضها مفهرس في # 8511 أو صفحة الويكي هذه ):

• البودكاست: Podcast.__init__ ، Test & Code ، FLOSS Weekly ، رحلة مطوري البرامج ، Real Python
• حفنة من التغريدات
• فيديو يوتيوب قصير عن التغييرات
• رسائل بريد إلكتروني إلى رعاة PyCon و PSF و PyPI من جهة اتصال رعاية PSF الخاصة بهم ، وتطلب منهم إخبار أقسام الهندسة الخاصة بهم بالتغييرات القادمة
• أرسل بريدًا إلكترونيًا إلى pypi-announce والقوائم المماثلة
• منشورات المدونة مثل هذه
• أرسل بريدًا إلكترونيًا إلى مجموعات التكنولوجيا المدنية والمجموعات المماثلة / مراكز الفكر

خلال الأشهر القليلة الماضية ، حصلنا على تدفق مستمر من المشكلات الجديدة من الأشخاص الذين يختبرون المحلل الجديد في 20.2 و 20.3 بيتا ، نقطة 20.3b1 . ساعدتنا هذه التقارير على تحسين وحدة الحل وإصلاح الأخطاء وتحسين تجربة المستخدم لمخرجاتها. لقد قمنا أيضًا بتحسين دليل المستخدم "ما الذي يتغير" بشكل كبير ، وذلك جزئيًا استجابة لملاحظات بيتا.

ها هي خطتي التقريبية:

* Start a discussion on discuss.python.org asking for support

* Direct folks to a Slack channel that could serve as a communication channel between everyone

* Start a document outlining some FAQ and our responses

* Include a decision tree for new issue -> triaged issue

* Share this with the channel once we have a known release date

* Try and roughly schedule volunteers to be online & triaging in the days following the release

di أدرك أن عدم اليقين والتأخيرات المستمرة من المحتمل أن تمنعك من القيام بالجدولة. تاريخ الإصدار الجديد غدًا الاثنين 30 نوفمبر. إذا كان لديك الآن سلسلة مناقشة وشجرة قرارات للمشاركة ، فالرجاء المضي قدمًا ومشاركتها!

تم إصدار النقطة 20.3 ، وهي تحتوي على المحلل الجديد افتراضيًا! إليك إعلان الإصدار على مدونة PSF: https://blog.python.org/2020/11/pip-20-3-release-new-resolver.html