Pip: خطأ في "نقطة الاستيراد" في النقطة 9.0.2

أستطيع أن أؤكد هذا أيضا. فقط على وشك تقديم نفس المشكلة.

هذه خدعة # 5079 - استيراد النقطة ليس حالة استخدام مدعومة (ولم تكن كذلك أبدًا).

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

أدى هذا أيضًا إلى كسر Anaconda وتوصلت إلى نفس الحل مثل Miserlou :

https://github.com/ContinuumIO/anaconda-issues/issues/8911

تم الإبلاغ عن الأخطاء عبر الكثير من المشاريع.

أزعجني هذا الخطأ أيضًا عندما كنت أحاول استخدام النقطة لتحديث متصفح الأناكوندا الخاص بي.

هل هناك أي فرصة للحصول على 9.0.3 التي تعمل على إصلاح هذا - من الناحية المثالية قريبًا جدًا؟

يؤثر هذا بالفعل على الكثير من المشاريع الكبرى (Anaconda و SpaCy و Zappa) ، وهناك أكثر من 850 ألف استخدام لهذا على GitHub وحده والتي تم كسرها الآن بواسطة تحديث إصدار "التصحيح" المفترض.

هل يمكنك على الأقل إعادة هذا التغيير الهائل في 9.0.3 ثم _announce_ إلى المصب الذي تعتزم تغيير هذا السلوك لإصدار 10.xx مستقبلي أو على الأقل 9.xx إصدار؟

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

كما نرى هذه النتيجة في بعض مشاريع OpenStack.

تستحق النقطة 10 في غضون شهر تقريبًا. كما أفهمها ، تكمن المشكلة في الكود الذي يستخدم import pip للوصول إلى الوظائف الداخلية للنقطة. لم ندعم مطلقًا مثل هذا الاستخدام رسميًا ، وقد وثقنا صراحةً هذا النقص في الدعم لبعض الوقت الآن (وإن كان ذلك فقط في الإصدار "الأحدث" من المستندات على https://pip.pypa.io/en/latest/user_guide / # using-pip-from-your-program ، لأنه لم يكن لدينا إصدار ثابت جديد منذ إضافة قسم المستند هذا). لقد أعلنا أيضًا عن إعادة تنظيم العناصر الداخلية لتوضيح أن استخدام واجهات برمجة التطبيقات الداخلية غير مدعوم ، في أكتوبر الماضي (راجع https://mail.python.org/pipermail/distutils-sig/2017-October/031642.html). سيؤدي هذا التغيير ، الموجود في النقطة 10 ، إلى كسر أي استخدام من هذا القبيل بغض النظر عن النقطة التي سيفعلها إصدار النقطة 9.0.3 المحتمل. لذلك من الصعب رؤية هذا على أنه كسر مفاجئ وغير متوقع.

إذا أراد dstufft إصدار إصدار طارئ 9.0.3 ، فأنا موافق على ذلك. لكنها ستكون فائدة قصيرة المدى فقط ، وأنا محبط بعض الشيء لأن الناس لم يبتعدوا بالفعل عن import pip . سيظل الأشخاص المتضررون من هذه المشكلة بحاجة إلى الاستعداد للنقطة 10 ، ويجب أن يفهموا أن مجرد التبديل إلى import pip._internal ليس شيئًا ندعمه أو نوصي به.

تعتبر مقترحات إعادة تقديم مستوى معين من دعم واجهة برمجة التطبيقات خيارًا بالتأكيد (انظر # 5080 على سبيل المثال) ولكن في هذه المرحلة ، فات الأوان لأي تغييرات من هذا القبيل لجعلها في النقطة 10.

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

نعم ، هذا هو نوع التغيير الذي يمكن أن يتوقعه الأشخاص من تحديث إصدار MAJOR . سيكون هذا جيدا.

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

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

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

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

Miserlou حسنًا ، أتناول وجهة نظرك - لقد استهدفنا تغيير التسمية الداخلية للنقطة 10 لأنها نسخة رئيسية. لا أعرف حقًا برامج التشغيل الخاصة بإصدار التصحيح - لقد أزعجنيdstufft ومن الواضح أنه لتجنب حدوث كسر كبير لمستخدمي نظام التشغيل Mac OS عندما يصلنا موعد نهائي وشيك لدعم TLS ، وهو قبل إصدار النقطة 10. توقعنا أن تكون المشكلات كبيرة بما يكفي لتبرير إصدار تصحيح قصير المدى. بالتأكيد لم تكن هناك نية لكسر الاستخدام الحالي.

يجب أن أترك قرار المتابعة 9.0.3 إلى dstufft - ليس لدي تفاصيل حول ما تم إدخاله في 9.0.2 أو أعرف ما إذا كان من الممكن تحديد كيفية إصلاح هذه المشكلة. ولا يمكنني الحكم على ما إذا كان سحب 9.0.2 تمامًا سيكون بمثابة فائدة عامة ، حيث ليس لدي أي فكرة عن عدد الأشخاص المتأثرين بمشكلة نظام التشغيل Mac OS. أفهم أن التثبيت على 9.0.1 (على الأقل بالنسبة لبعض الأشخاص) يعد حلاً ، لذلك قد ينتهي به الأمر ليكون الخيار الأقل سوءًا.

ستؤثر مشكلة macOS TLS على كل شخص يستخدم نظام Python على نظام macOS <10.13

يجب أن أترك قرار المتابعة 9.0.3 لـ dstufft

أنا في نفس موقعpfmoore.

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

نفس المشكلة هنا مع النقطة 9.0.2 في gitlab-ci مع Docker python 3.4: KeyError

  File "/usr/local/lib/python3.4/site-packages/pip/__init__.py", line 45, in <module>
    from pip.vcs import git, mercurial, subversion, bazaar  # noqa
  File "/usr/local/lib/python3.4/site-packages/pip/vcs/mercurial.py", line 9, in <module>
    from pip.download import path_to_url
  File "/usr/local/lib/python3.4/site-packages/pip/download.py", line 40, in <module>
    from pip._vendor import requests, six
  File "/usr/local/lib/python3.4/site-packages/pip/_vendor/requests/__init__.py", line 98, in <module>
    from . import packages
  File "/usr/local/lib/python3.4/site-packages/pip/_vendor/requests/packages.py", line 12, in <module>
    sys.modules['pip._vendor.requests.packages.' + mod] = sys.modules["pip._vendor." + mod]
KeyError: 'pip._vendor.urllib3.contrib'

تم إصدار 9.0.2 لمعلوماتك مع عمليات البناء المكسورة:

مرجع Travis-CI: https://travis-ci.org/pypa/pip/builds/354616774؟utm_source=github_status&utm_medium=notification

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

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

إذا أراد dstufft إصدار إصدار طارئ 9.0.3 ، فأنا موافق على ذلك. لكنها ستكون فائدة قصيرة المدى فقط ، وأنا محبط بعض الشيء لأن الناس لم يبتعدوا بالفعل عن نقطة الاستيراد. سيظل الأشخاص المتضررون من هذه المشكلة بحاجة إلى الاستعداد للنقطة 10 ، ويجب أن يفهموا أن مجرد التبديل إلى استيراد نقطة ._internal ليس شيئًا ندعمه أو نوصي به.

لا أستطيع أن أصدق أن هذا بيان من مالك هذا المستودع ... لقد قلت للتو "إصدار f * ck الدلالية" و "من يحتاج إلى سياسة إهمال على أي حال".

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

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

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

هذا مجرد إلقاء اللوم لأنك لا تحب أن تكون على خطأ

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

هذا مجرد إلقاء اللوم لأنك لا تحب أن تكون على خطأ

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

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

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

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

@ انكس-كريكوزبيرجر

لا أستطيع أن أصدق أن هذا بيان من مالك هذا المستودع ... لقد قلت للتو "إصدار f * ck الدلالية" و "من يحتاج إلى سياسة إهمال على أي حال".

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

إذا كنت تريد توجيه اتهامات من هذا القبيل ، يرجى دعمها

1. مؤشر إلى بيان من أي من المشرفين على النقاط الذي ندعمه باستخدام واجهة برمجة التطبيقات الداخلية للنقطة في كود المستخدم.
2. مؤشر إلى بيان من أي من المشرفين على النقطة أن النقطة تستخدم الإصدارات الدلالية.

لا أعتقد أنك ستجد هذا الدليل ...

أنت تقول إنني مخطئ في استخدام حزم الجهات الخارجية التي تعتمد على ميزة غير موثقة من النقطة.

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

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

حاولنا تقديم تحذير. لقد أرسلنا إعلانات منذ أشهر ، وأضفنا مستندات تشرح الموقف ، وأجبنا باستمرار على المشكلات الموجودة في أداة التتبع تفيد بأن استخدام واجهات برمجة التطبيقات الداخلية غير مدعوم. إن إضافة الإهمال ليس سهلاً كما تقترح ، لأن النقطة نفسها ستطلق هذه التحذيرات (أو ستكون هناك طريقة لإيقافها ، والتي قد ينسخها الآخرون فقط - لقد سمعنا بالفعل عن أشخاص يخططون لـ استيراد pip._internal ، لذلك حتى هذا التغيير لن يوقفهم: محبط :).

بالنسبة إلى "إصلاح" هذا ، سأعترف بسعادة أنه تم إصدار 9.0.2 بسرعة لمعالجة مشكلة ملحة ، ولم نتوقع هذه المشكلة. ربما يكون إطلاق 9.0.3 مع عمر 2-3 أسابيع أمرًا معقولاً ، لا أعتقد ذلك بنفسي ، لكني ذكرت أننا سننظر في ذلك. لا يمكنني أن أوافق شخصيًا على القيام بذلك ، لأنني لست من المشاركين في إصدارات 9.0.x. أنا أعمل على النقطة 10 ، مما سيجعل كل هذا النقاش غير ذي صلة ، لذلك من المحتمل أن تكون هذه هي كلمتي الأخيرة حول هذه المسألة - أحتاج إلى التركيز على الأشياء المتعلقة بهذا الإصدار.

نصيحتي الشخصية:

1. قم بالتثبيت إلى 9.0.1 إذا كنت متأثرًا بهذا وتحتاج إلى حل بديل الآن .
2. كن مستعدًا للنقطة 10 ، عندما تنكسر جميع التبعيات التي لديك حاليًا لأنها تستخدم واجهات برمجة التطبيقات الداخلية للنقطة مرة أخرى. ادفع تلك التبعيات لاتخاذ إجراءات بشأن المعلومات التي قدمناها لأشهر ، ويسعدك تلقيك تحذيرًا مسبقًا بحدوث ذلك.
3. إذا تم تحرير النقطة 9.0.3 ، فقم بإزالة الدبوس.
4. من فضلك ، اختبر Pip 10 beta عندما يخرج ، وأبلغ الأطراف ذات الصلة بأي مشاكل (مشاريع الطرف الثالث إذا كانوا يتصلون بالنقطة داخليًا ، نحن إذا كنت تستدعي pip بنفسك).

لقد واجهت نفس المشكلة مع pip 9.0.2 و Python 2.7.14 داخل حاوية عامل إرساء.
لا يمكنني إعادة إنتاج المشكلة على جهازي المطوّر خارج حاوية عامل إرساء.
لقد بحثت عن استيراد نقطة (grep'd لـ import.pip ، from.pip ، \'pip ، \"pip ) ولكن لم أجد أي شيء.
نحن في __import__ نستخدم آلية لتضمين التكوينات تلقائيًا من الحزم المضمنة في ملف setup.

هذا هو الجزء المناسب من التتبع:

  File "/home/plone/.buildout/shared-eggs/zope.configuration-3.7.4-py2.7.egg/zope/configuration/xmlconfig.py", line 359, in endElementNS
    self.context.end()
  File "/home/plone/.buildout/shared-eggs/zope.configuration-3.7.4-py2.7.egg/zope/configuration/config.py", line 558, in end
    self.stack.pop().finish()
  File "/home/plone/.buildout/shared-eggs/zope.configuration-3.7.4-py2.7.egg/zope/configuration/config.py", line 706, in finish
    actions = self.handler(context, **args)
  File "/home/plone/.buildout/shared-eggs/z3c.autoinclude-0.3.7-py2.7.egg/z3c/autoinclude/zcml.py", line 51, in includeDependenciesDirective
    info = DependencyFinder(dist).includableInfo(['configure.zcml', 'meta.zcml'])
  File "/home/plone/.buildout/shared-eggs/z3c.autoinclude-0.3.7-py2.7.egg/z3c/autoinclude/dependency.py", line 26, in includableInfo
    module = resolve(dotted_name)
  File "/home/plone/.buildout/shared-eggs/zope.dottedname-4.2-py2.7.egg/zope/dottedname/resolve.py", line 39, in resolve
    found = __import__(used)
  File "/plone/buildout/lib/python2.7/site-packages/pip/__init__.py", line 45, in <module>
    from pip.vcs import git, mercurial, subversion, bazaar  # noqa
  File "/plone/buildout/lib/python2.7/site-packages/pip/vcs/mercurial.py", line 9, in <module>
    from pip.download import path_to_url
  File "/plone/buildout/lib/python2.7/site-packages/pip/download.py", line 40, in <module>
    from pip._vendor import requests, six
  File "/plone/buildout/lib/python2.7/site-packages/pip/_vendor/requests/__init__.py", line 98, in <module>
    from . import packages
  File "/plone/buildout/lib/python2.7/site-packages/pip/_vendor/requests/packages.py", line 12, in <module>
    sys.modules['pip._vendor.requests.packages.' + mod] = sys.modules["pip._vendor." + mod]
zope.configuration.xmlconfig.ZopeXMLConfigurationError: File "/plone/buildout/parts/instance/etc/site.zcml", line 15.2-15.55
    ZopeXMLConfigurationError: File "/plone/buildout/parts/instance/etc/package-includes/002-bda.aaf.site-configure.zcml", line 1.0-1.56
    ZopeXMLConfigurationError: File "/plone/buildout/src-aaf/bda.aaf.site/src/bda/aaf/site/configure.zcml", line 11.2-11.48
    ZopeXMLConfigurationError: File "/plone/buildout/src-aaf/bda.aaf.site/src/bda/aaf/site/configure-dependencies.zcml", line 10.2-10.39
    ZopeXMLConfigurationError: File "/plone/buildout/src-addons/plone.app.mosaic/src/plone/app/mosaic/configure.zcml", line 9.2-9.39
    ZopeXMLConfigurationError: File "/home/plone/.buildout/shared-eggs/plone.app.tiles-3.0.3-py2.7.egg/plone/app/tiles/configure.zcml", line 18.2-18.41
    ZopeXMLConfigurationError: File "/plone/buildout/src/plone.app.z3cform/plone/app/z3cform/configure.zcml", line 10.2-10.41
    ZopeXMLConfigurationError: File "/plone/buildout/src/plone.app.widgets/plone/app/widgets/configure.zcml", line 12.2-12.41
    ZopeXMLConfigurationError: File "/home/plone/.buildout/shared-eggs/Products.CMFPlone-5.1.0.1-py2.7.egg/Products/CMFPlone/configure.zcml", line 15.2-15.46
    ZopeXMLConfigurationError: File "/home/plone/.buildout/shared-eggs/plone.app.contenttypes-1.4.9-py2.7.egg/plone/app/contenttypes/configure.zcml", line 10.2-10.37
    KeyError: 'pip._vendor.urllib3.contrib'

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

فكر في الأمر بهذه الطريقة: النقطة هي أداة مساعدة لسطر الأوامر وليست مكتبة. حقيقة أنه مكتوب بلغة بايثون ليست ذات صلة. هذا هو حقيقة الأمر.

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

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

فكر في الأمر بهذه الطريقة: النقطة هي أداة مساعدة لسطر الأوامر وليست مكتبة. حقيقة أنه مكتوب بلغة بايثون ليست ذات صلة. هذا هو حقيقة الأمر.

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

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

ماذا تتوقع أن يحدث بعد ذلك؟

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

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

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

@ الكل ، لا يساعد اتهام المشرفين على التعليمات البرمجية المعطلة في حل المشكلة.

فكر في الأمر بهذه الطريقة: النقطة هي أداة مساعدة لسطر الأوامر وليست مكتبة. حقيقة أنه مكتوب بلغة بايثون ليست ذات صلة. هذا هو حقيقة الأمر.

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

بادئ ذي بدء ، آسف إذا اتهمت القائمين على صيانة الريبو بالشفرة الخاطئة. تم توجيه أي اتهام بسبب الإحباط ، وإذا كان الأمر كذلك ، فأشر إلى حقيقة أن إصدار IMHO 9.0.2 هو من خلال تعريف semver لإصدار تصحيح (على الرغم من أن pfmoore أوضح أن النقطة لا تستخدم بالضرورة semver - والتي هي مشكلة أخرى ليوم آخر على ما أعتقد).

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

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

علم. أعني إلقاء نظرة على مديري حزم JavaScripts: npm ، bower ، yarn ، كل ما سيتم إصداره في الأسبوع القادم ~ العام ~ الأسبوع

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

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

حاولنا تقديم تحذير. لقد أرسلنا إعلانات منذ أشهر ، أضفنا مستندات تشرح الوضع

هل هذا بالنسبة للنقطة 9.0.2 أم للنقطة 10؟ إذا كان الأمر يتعلق بالنقطة 9.0.2 ، فسوف أجد أنه من الجيد وجود ملاحظة في سجل التغيير . على أي حال ، شكرًا لكونك استباقيًا جدًا في تطوير النقطة 10 وإرسال إعلانات حول عدم استخدام import pip ، هذا جيد! أبقه مرتفعا!

إن إضافة الإهمال ليس سهلاً كما تقترح ، لأن النقطة نفسها ستطلق هذه التحذيرات (أو ستكون هناك طريقة لإيقافها ، والتي قد ينسخها الآخرون فقط - لقد سمعنا بالفعل عن أشخاص يخططون لـ استيراد pip._internal ، لذلك حتى هذا التغيير لن يمنعهم من الإحباط).

لا أعتقد أن هذا سيكون صعبًا جدًا ... لديك هذا بالفعل في __init__.py :

if __name__ == '__main__':
    sys.exit(main())

ماذا عن مجرد إضافة آخر؟

if __name__ == '__main__':
    sys.exit(main())
else:
    logger.warning("You are importing PIP as a Python library. This behaviour is deprecated and should no longer be used. We will break the API with version 10.0!!!111eleven Please see https://pip.readthedocs.org/some_link_where_you_explain_this.html")

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

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

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

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

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

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

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

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

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

شكرا لك. الإحباط مرتفع هنا ، وأنا أتفهم ذلك.

ماذا عن مجرد إضافة آخر؟

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

هل هذا بالنسبة للنقطة 9.0.2 أم للنقطة 10؟

مقابل 10.0. لم تكن هناك نية أصلية لإصدار 9.0.2 ، لكننا فعلنا ذلك فقط كإصدار طارئ حتى لا يفقد مستخدمو نظام التشغيل Mac OS كل إمكانية الوصول إلى PyPI عندما تدخل تغييرات TLS حيز التنفيذ.

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

أجد هذا "التهديد" دائمًا مسليًا.

إنه ليس تهديدًا على الإطلاق ، أعتذر إذا حدث بهذه الطريقة.

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

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

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

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

مرحبًا dstufft ، شكرًا للتناغم. هذا الموضوع يزداد سخونة!

بادئ ذي بدء ، أشكرك على عملك! أعلم أن الصيانة مهمة لا نهاية لها ولا شك فيها ، وأتصور أنها تزداد سوءًا عندما تدير مشروعًا كبيرًا وشائعًا مثل pip !

الآن ، فيما يتعلق بالمشكلة المطروحة: على الرغم من أن عشرين _ صيانة_ قد أبلغوا عن هذه المشكلة حتى الآن ، فأنا أعلم أن هذا يؤثر بالفعل على الآلاف من الأشخاص - بعض المشاريع المتأثرة ضخمة بحد ذاتها: Anaconda و OpenStack و SpaCy و Zappa و have عشرات الآلاف من المستخدمين. أعلم أن قناتنا على Slack مليئة بالمناقشات حول هذا الموضوع. (حرفيا ، بينما كنت أكتب هذا ، ظهر عدد جديد.)

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

أعتقد أن الوضع حتى الآن هو:

• نظرًا لتنسيق سلسلة الإصدار ، اعتقدنا جميعًا أن المشرفين على صيانة الأنابيب يتبعون الإصدارات الدلالية
• أصدر القائمون على صيانة الأنابيب "تصحيحًا" أدخل تغييرًا هائلاً في كسر الأنابيب
• كان هذا التغيير غير معلن وغير موثق - وأفترض أنه غير متوقع وغير مقصود
• الآن ، مجرد استدعاء import pip يكسر البرنامج فورًا ، والذي يعد معاديًا للغاية للمطورين
• هذا يسبب صداعًا كبيرًا عبر نظام Python البيئي
• لا تحذر الوثائق (و _ لا تزال _ لا - انقر فوق ارتباط المستندات في README هذا في الريبو) من استخدام pip برمجيًا.
• لم يكن هناك إعلان بأن import pip سيتسبب في هذا الضرر في تحديث PATCH - جاء هذا الإعلان لإصدار _ لم يتم إصداره بعد_.
• لم يذكر هذا التغيير حتى في سجل التغيير
• لا نريد استبدال Pip أو مطوري Pip! نحن نحبك!
• .. لكننا لا نريد أن يحدث هذا النوع من الأشياء مرة أخرى!
• .. لذلك نريد أن يتبع سمفر!
• نود حقًا ، حقًا ، PATCH آخر الذي يلغي هذا التغيير الكبير!

تعد الحاجة إلى طريقة برمجية لفحص بيئة في لحظة> = 10.0.0 عالم موضوع مناقشة أخرى ، ولكن حقيقة الأمر المطروح هو أنه لم يتم إخبارنا أبدًا بأنه لا ينبغي استخدام النقطة برمجيًا في النقطة <= 9 world ، وكان هناك تغيير هائل غير معلن ، ونود حقًا أن نراه معكوسًا لأنه يؤثر سلبًا على آلاف الأشخاص.

شكرا لك مرة أخرى،
ثري

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

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

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

أنا متأكد تمامًا من أن المقياس متحيز بشدة بواسطة جميع أوامر pip install pip --upgrade الآلية من أنظمة التكامل المستمر / التسليم (يجب أن يستخدموا ذاكرات التخزين المؤقت ، وبالتالي لا يحتاجون إلى إعادة تثبيت الحزم من pypi طوال الوقت ؛ ولكن في في الوقت نفسه ، لا ينبغي للمرء أيضًا أن يفعل import pip ... هذه هي الطريقة التي يعمل بها عالم تكنولوجيا المعلومات).

حقيقة أن (أقل من) 15 شخصًا اشتكوا من هذا يجب أن تُظهر شيئين:

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

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

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

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

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

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

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

على المدى الطويل ، من المحتمل أن نتحرك نحو مخطط إصدار قائم على التاريخ (نأمل) لإزالة أي ارتباك حول ما إذا كنا نصف أم لا.

مرسل من الايفون الخاص بي

في 20 آذار (مارس) 2018 الساعة 11:02 صباحًا ، كتب Rich Jones [email protected] :

مرحبًا dstufft ، شكرًا للتناغم. هذا الموضوع يزداد سخونة!

بادئ ذي بدء ، أشكرك على عملك! أعلم أن الصيانة مهمة لا نهاية لها ولا شك فيها ، وأتصور أنها تزداد سوءًا عندما تدير مشروعًا كبيرًا وشائعًا مثل PIP!

الآن ، بالنسبة إلى المشكلة المطروحة: على الرغم من أن عشرين مشرفًا قد أبلغوا عن هذه المشكلة حتى الآن ، فأنا أعلم أن هذا يؤثر بالفعل على آلاف الأشخاص - فبعض المشاريع المتأثرة ضخمة بحد ذاتها: Anaconda و OpenStack و SpaCy و Zappa و have عشرات الآلاف من المستخدمين. أعلم أن قناتنا على Slack مليئة بالمناقشات حول هذا الموضوع. (حرفيا ، بينما كنت أكتب هذا ، ظهر عدد جديد.)

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

أعتقد أن الوضع حتى الآن هو:

نظرًا لتنسيق سلسلة الإصدار ، اعتقدنا جميعًا أن المشرفين على صيانة الأنابيب يتبعون الإصدارات الدلالية
أصدر القائمون على صيانة الأنابيب "تصحيحًا" أدخل تغييرًا هائلاً في كسر الأنابيب
كان هذا التغيير غير معلن وغير موثق - وأفترض أنه غير متوقع وغير مقصود
الآن ، مجرد استدعاء نقطة الاستيراد يكسر على الفور البرنامج ، وهو برنامج معاد للغاية للمطور
هذا يسبب صداعًا كبيرًا عبر نظام Python البيئي
لا تحذر الوثائق (ولا تزال لا تفعل ذلك - انقر فوق ارتباط المستندات في ملف README هذا في الريبو) من استخدام النقطة برمجيًا.
لم يكن هناك إعلان بأن استيراد نقطة من شأنه أن يسبب هذا الضرر في تحديث PATCH - جاء هذا الإعلان لإصدار لم يتم إصداره بعد.
لم يذكر هذا التغيير حتى في سجل التغيير
لا نريد استبدال Pip أو مطوري Pip! نحن نحبك!
.. لكننا لا نريد أن يحدث هذا النوع من الأشياء مرة أخرى!
.. لذلك نريد أن يتبع سمفر!
نود حقًا ، حقًا ، الحصول على تصحيح آخر يلغي هذا التغيير الكبير!
تعد الحاجة إلى طريقة برمجية لفحص بيئة في لحظة> = 10.0.0 عالم موضوع مناقشة أخرى ، ولكن حقيقة الأمر المطروح هو أنه لم يتم إخبارنا أبدًا بأنه لا ينبغي استخدام النقطة برمجيًا في النقطة <= 9 world ، وكان هناك تغيير هائل غير معلن ، ونود حقًا أن نراه معكوسًا لأنه يؤثر سلبًا على آلاف الأشخاص.

شكرا لك مرة أخرى،
ثري

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

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

نظرًا لتنسيق سلسلة الإصدار ، اعتقدنا جميعًا أن المشرفين على صيانة الأنابيب يتبعون الإصدارات الدلالية

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

ردًا على هذا التعليق : سواء التزمت pip بـ semver أم لا ، أو وعدت بالالتزام بها ، فإن استخدام مخطط إصدار major.minor.micro لا يزال يحمل وعدًا ضمنيًا بنوع من ضبط النفس حول الإصدارات الصغيرة. إذا كان دبوس الإصدار المتوافق مثل ~= 9.0.1 غير كافٍ لحماية المستخدمين من الانقطاعات غير المتوقعة في التوافق مع الإصدارات السابقة ، فإن البديل الآمن الوحيد المتبقي هو مطابقة الإصدار العادي. إذا لم تكن هناك نية لدعم أي شيء أكثر من مطابقة الإصدار ، فقد تتحول النقطة أيضًا إلى نظام إصدار على غرار Chrome يحتوي على مكون واحد فقط يتزايد بشكل رتيب.

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

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

جانبا ، يمكنني إعادة إنتاج هذا في virtualenv (2 أو 3 ، لا يهم) من خلال الخطوات التالية:

virtualenv -p python3 /tmp/pip
/tmp/pip/bin/pip install -e path/to/clone/of/pip/9.0.2
/tmp/pip/bin/pip install requests
/tmp/pip/bin/python

ثم ، داخل قشرة الثعبان:

>>> import requests
>>> import pip

إذا لم يتم استيراد الطلبات بالفعل ، سينجح import pip .

فواصل غير متوقعة في التوافق مع الإصدارات السابقة

يرجى توضيح المكان الذي تم فيه توثيق import pip ليكون واجهة برمجة تطبيقات مستقرة تندرج تحت وعود التوافق العكسي التي نقدمها؟ أود التأكد من إزالة هذه الوثائق لأننا لا ندعم هذا الاستخدام بشكل قاطع.

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

pip هو مدير حزم Python. بايثون هي لغة برمجة. يحتاج الناس إلى فحص بيئاتهم برمجيًا. 1 + 1 = 2.

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

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

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

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

لم يكن هناك - ولا يوجد - أي شيء في الوثائق ينص على عدم القيام بذلك.

https://pip.pypa.io/en/latest/user_guide/#using -pip-from-your-program

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

Miserlou أعتقد أن هذه الملاحظة هي لطف للأشخاص الذين يعتقدون بطريقة ما أنه يجب عليهم استيراد العناصر الداخلية لأداة سطر الأوامر لمجرد أنه يتم تنفيذها في Python وهذه العناصر الداخلية قابلة للاستيراد.

أتفهم أن لديك تفسيرًا مختلفًا للواجهة العامة pip مني ، والمطورين ومعظم الأشخاص الذين يفكرون في pip كبرنامج CLI ، ولكن ما هو الضرر الفعلي لهذا؟ ما عليك سوى تثبيت pip != 9.0.2 والانتهاء من ذلك.

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

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

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

أعتقد أنه من غير المرجح أن تكون هذه المناقشة مثمرة ولا يوجد حقًا أي شيء إضافي يمكن قوله. يوجد:

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

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

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

حسنًا ، آخر شيء أقسمه - نقلت النقطة 10 بالفعل كل الشفرة ذات الصلة إلى pip._internal (لم نستخدم _pip لأن ذلك قد يكسر python -m pip ، وهو المدعوم).

هل يمكن لأي شخص التحقق مما إذا كان https://github.com/pypa/pip/pull/5100 يحل هذا الأمر بالنسبة لهم؟

خدش ، أعتقد أن # 5100 خاطئ ، هل يمكنك التحقق من https://github.com/pypa/pip/pull/5101 بدلاً من ذلك.

dstufft يمكنني أن أؤكد ، الإصلاح في # 5101 يحل المشكلة بالنسبة لي.

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

للتسجيل في هذا الموضوع ، حل # 5101 مشكلتي أيضًا.

كما سبق ، يسمح # 5101 للاستيراد بالعمل داخل أداتنا. مصدر التحذير: لم أختبر النقطة المصححة ولا أداتنا على نطاق واسع.

يجب أن يتم إصلاح هذا في 9.0.3.

شكرًا على الحل السريع ، من شخص لم يكتب أبدًا import pip في حياته ولكنه كان مستهلكًا لحزمة فعلت ذلك. بعد قراءة سلسلة الرسائل هذه ، يبدو أن الكثير من التطبيقات قد استوردت pip ، دون علم مقابل أفضل الممارسات ، ومن المحتمل أن يتأثر الكثير من المطورين والمستخدمين بالإصدارين v9.0.2 و v10.

أنا ثانيًا / ثالثًا / لا يتم إضافة تحذير إهمال مناسب لجعل الأمور أكثر سلاسة. ربما حتى آخر pypi.python.org؟

الصيحة! شكرا على هذا!

أحب أيضًا تحذيرًا من الإهمال ، والأهم من ذلك - تعليمات مناسبة حول كيفية فحص بيئات Python برمجيًا في عالم pip10! من الواضح أن هناك حاجة لذلك ، نظرًا لأن أكثر من 700000 تطبيق قد تأثر بهذا الخطأ.

pip list --format=json ؟

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

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

إليكم قصة مماثلة: https://public-inbox.org/git/1267957655.3759.29.camel@mattotaupa/T/

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

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

sruggier الحزم المحددة كلها جيدة ، ويحتاج WheelFile.install () أيضًا إلى مزيد من الترويج. لكن خدمة الشباك pip.main() المقدمة لا يمكن الاستغناء عنها مع كل ما سبق. لا يزال الأمر يستحق المحاولة.

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

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

إذا كنت تصر على استخدام النقطة كمرجع ، فستحتاج إلى إعادة النظر في الكثير من الافتراضات.

drunkwcodes فقط لكي تكون واضحًا ، pip.main() هو أسهل استخدام للاستبدال - تحتاج ببساطة إلى استخدام subprocess.run([sys.executable, '-m', 'pip', <rest of args>]) .

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

أنا أقدر العمل الذي تقومون به جميعًا ، وأعلم أنه ليس بالأمر السهل. لكن للتسجيل:

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

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

تعليمات مناسبة حول كيفية فحص بيئات Python برمجيًا في عالم pip10

ما هو موقف PyPA على Distlib؟ من الواضح أن Pip يستخدمه في بعض السعة ، ولكنه يستخدم أيضًا التغليف ، والذي يهدف Distlib إلى إهماله.

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

لست على علم بأن Distlib يعيق التغليف. يذكر "distutils2 / Packaging" لكن المقطعات 2 كانت شيئًا مختلفًا.

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

ربما يكون الاستنكار قويًا جدًا للكلمة إذن. مصدر فهمي الحالي:

https://distlib.readthedocs.io/en/latest/overview.html#distlib -evolved-out-of-Packaging

آه ، هذه "عبوة" مختلفة - كانت وحدة stdlib المقترحة التي تهدف إلى استبدال المقطوعات. إنه مختلف تمامًا عن مشروع PyPI packaging . قد يكون من المفيد أن نطلب من مشروع distlib توضيح هذا التمييز بشكل أفضل قليلاً.

قد يكون من المفيد أن نطلب من مشروع distlib توضيح هذا التمييز بشكل أفضل قليلاً.

فعلت ذلك بالفعل :) انظر: https://bitbucket.org/pypa/distlib/issues/100/clarify-project-positioning-and-status

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