Pipenv: لا يمكن حل التبعيات. تراجع؟

يبدو أن pipenv يضيف دبوسًا صارمًا إلى الجولة المرشحة الحالية.

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

لست متأكدًا مما يسبب هذا.
لقد لاحظت أنه لإعادة إنتاج هذا ، يجب علي مسح ذاكرة التخزين المؤقت ( --clear ) إذا استخدمت pip-tools بمفرده من قبل.
أستطيع أن أقول أن هذا ليس خطأ pip-tools ، ولا يرتبط بشكل مباشر بملفات pip-tools (أزلتها جميعًا للمحاولة ، ولا يزال هذا يحدث).
آمل أن يساعد هذا.

حسنًا ، وجدت الجاني:
https://github.com/kennethreitz/pipenv/blob/master/pipenv/patched/pip/req/req_set.py#L752

self.requirements.values() على req_to_install نفسه ، وهو مُثبَّت ، وهو أمر خاطئ لإعادته كتبعية ، ويمكن أن يؤدي إلى فشل حل التبعية ، كما هو الحال هنا ، إذا كانت الحزمة اللاحقة تتطلب إصدارًا لا يناسب المرشح الحالي. القيام بذلك يفترض أن مرشحنا الأول يجب أن يكون المرشح المناسب ، أو يفشل ..

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

أعتقد أنني أرى نفس المشكلة:

$ pipenv --version
pipenv, version 8.2.7

$ pipenv install
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Could not find a version that matches django==2.0a1,>=1.8,>=1.8.0
Tried: 1.1.3, 1.1.4, 1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6, 1.2.7, 1.3, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.3.5, 1.3.6, 1.3.7, 1.4, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.4.5, 1.4.6, 1.4.7, 1.4.8, 1.4.9, 1.4.10, 1.4.11, 1.4.12, 1.4.13, 1.4.14, 1.4.15, 1.4.16, 1.4.17, 1.4.18, 1.4.19, 1.4.20, 1.4.21, 1.4.22, 1.5, 1.5.1, 1.5.2, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.8, 1.5.9, 1.5.10, 1.5.11, 1.5.12, 1.5.12, 1.6, 1.6, 1.6.1, 1.6.1, 1.6.2, 1.6.2, 1.6.3, 1.6.3, 1.6.4, 1.6.4, 1.6.5, 1.6.5, 1.6.6, 1.6.6, 1.6.7, 1.6.7, 1.6.8, 1.6.8, 1.6.9, 1.6.9, 1.6.10, 1.6.10, 1.6.11, 1.6.11, 1.7, 1.7, 1.7.1, 1.7.1, 1.7.2, 1.7.2, 1.7.3, 1.7.3, 1.7.4, 1.7.4, 1.7.5, 1.7.5, 1.7.6, 1.7.6, 1.7.7, 1.7.7, 1.7.8, 1.7.8, 1.7.9, 1.7.9, 1.7.10, 1.7.10, 1.7.11, 1.7.11, 1.8a1, 1.8b1, 1.8b2, 1.8rc1, 1.8, 1.8, 1.8.1, 1.8.1, 1.8.2, 1.8.2, 1.8.3, 1.8.3, 1.8.4, 1.8.4, 1.8.5, 1.8.5, 1.8.6, 1.8.6, 1.8.7, 1.8.7, 1.8.8, 1.8.8, 1.8.9, 1.8.9, 1.8.10, 1.8.10, 1.8.11, 1.8.11, 1.8.12, 1.8.12, 1.8.13, 1.8.13, 1.8.14, 1.8.14, 1.8.15, 1.8.15, 1.8.16, 1.8.16, 1.8.17, 1.8.17, 1.8.18, 1.8.18, 1.9a1, 1.9b1, 1.9rc1, 1.9rc2, 1.9, 1.9, 1.9.1, 1.9.1, 1.9.2, 1.9.2, 1.9.3, 1.9.3, 1.9.4, 1.9.4, 1.9.5, 1.9.5, 1.9.6, 1.9.6, 1.9.7, 1.9.7, 1.9.8, 1.9.8, 1.9.9, 1.9.9, 1.9.10, 1.9.10, 1.9.11, 1.9.11, 1.9.12, 1.9.12, 1.9.13, 1.9.13, 1.10a1, 1.10a1, 1.10b1, 1.10b1, 1.10rc1, 1.10rc1, 1.10, 1.10, 1.10.1, 1.10.1, 1.10.2, 1.10.2, 1.10.3, 1.10.3, 1.10.4, 1.10.4, 1.10.5, 1.10.5, 1.10.6, 1.10.6, 1.10.7, 1.10.7, 1.10.8, 1.10.8, 1.11a1, 1.11b1, 1.11rc1, 1.11rc1, 1.11, 1.11, 1.11.1, 1.11.1, 1.11.2, 1.11.2, 1.11.3, 1.11.3, 1.11.4, 1.11.4, 1.11.5, 1.11.5, 1.11.6, 1.11.6, 2.0a1

حيث من الواضح أن 2.0a1 هو أحد الخيارات المتاحة.

لا يمكنني اختبار دقة التبعية في أي إصدارات قديمة من pipenv بسبب https://github.com/kennethreitz/pipenv/issues/786. في رأيي ، يجب تطبيق إصلاحات الأخطاء الحرجة على عدد قليل على الأقل من أحدث الإصدارات الرئيسية.

نفس المشكلة - إنها تشكو من الطلبات على وجه التحديد.

أعتقد أن هذا خطأ يتعلق بتعليقvilippon . لا أعتقد أنه مرتبط بـ # 909.

دقيق ، لا علاقة له بالرقم 909.
كما قلت ، سأحتاج إلى مدخلات من أحد maintainers لفهم ما يعنيه هنا بالضبط "حل

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

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

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

nateprewitt Allright ، سأضيف قدر ما أستطيع. الاستيلاء على كرسي.

ماالخطب؟

في https://github.com/kennethreitz/pipenv/issues/875#issuecomment -335570812 ، لاحظت مصدر الخطأ: تمت إضافة المرشحين المختارين في جولة حل كاتبعية مثبتة للمرشح نفسه مباشرةً ، وهو خطأ ( المزيد عن ذلك قادم)

في https://github.com/kennethreitz/pipenv/issues/875#issuecomment -336609268 ، وجدت مصدر هذا الدبوس: self.requirements.values() الذي تمت إضافته إلى القيمة المرتجعة يتضمن دبوسًا إلى الحزمة الحالية . بعبارة أخرى ، يجب أن يقوم _prepare_file بإرجاع تبعيات الحزمة (أو "قائمة بمتطلبات التثبيت الإضافية للتثبيت أيضًا") ، ولكنها الآن تتضمن نفسها ، مثبتة ، باعتبارها تابعة لها.

للمساعدة في توضيح سبب خطأ تثبيت الحزمة نفسها ، باعتبارها تبعية خاصة بها ، فإليك كيفية عمل خوارزمية حل التبعية ، باختصار:

1. احصل على initial_constraints_set ، قائمة InstallRequirements (على سبيل المثال: requests>=2.18 ).
2. حدد additional_constraints و candidate كمجموعة فارغة.
3. حدد مجموعة من candidate (على سبيل المثال: requests==2.18.4 ) التي تحترم اتحاد initial_constraints_set و additional_constraints
4. لكل مرشح ، احصل على مجموعة تبعيات كل المرشحين واجمعها ، مثل additional_constraints (على سبيل المثال: certifi>=2017.4.17 )
5. إذا تغير additional_constraints ، امسح candidate وارجع إلى 3.
6. أعد مجموعة المرشح ، تم.

الآن ، دعنا نعيد إنتاج المشكلة مع وضع ما سبق في الاعتبار.

لإعادة إظهار المشكلة ، تحتاج إلى هذا Pipfile (لأنه تم إصدار `django-cms 3.4.5 بدعم Django 1.11):

[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true

[packages]
django-cms = "==3.4.4"
django = "*"

والآن pipenv lock --verbose --clear :

Courtesy Notice: Pipenv found itself running within a virtual environment, so it will automatically use that environment, instead of creating its own for any project.
Locking [dev-packages] dependencies…
Using pip: -i https://pypi.python.org/simple

                          ROUND 1
Current constraints:

Finding the best candidates:

Finding secondary dependencies:
------------------------------------------------------------
Result of round 1: stable, done
Locking [packages] dependencies…
Using pip: -i https://pypi.python.org/simple

                          ROUND 1
Current constraints:
  django
  django-cms==3.4.4

Finding the best candidates:
  found candidate django==1.11.6 (constraint was <any>)
  found candidate django-cms==3.4.4 (constraint was ==3.4.4)

Finding secondary dependencies:
  django-cms==3.4.4 not in cache, need to check index
  django-cms==3.4.4         requires django-classy-tags>=0.7.2, django-cms==3.4.4, django-formtools>=1.0, django-sekizai>=0.7, django-treebeard>=4.0.1, Django<1.11,>=1.8, djangocms-admin-style>=1.0
  django==1.11.6 not in cache, need to check index
  django==1.11.6            requires django==1.11.6, pytz

New dependencies found in this round:
  adding [u'django', '<1.11,==1.11.6,>=1.8', '[]']
  adding [u'django-classy-tags', '>=0.7.2', '[]']
  adding [u'django-cms', '==3.4.4', '[]']
  adding [u'django-formtools', '>=1.0', '[]']
  adding [u'django-sekizai', '>=0.7', '[]']
  adding [u'django-treebeard', '>=4.0.1', '[]']
  adding [u'djangocms-admin-style', '>=1.0', '[]']
  adding [u'pytz', '', '[]']
Removed dependencies in this round:
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 1: not stable

                          ROUND 2
Current constraints:
  django<1.11,==1.11.6,>=1.8
  django-classy-tags>=0.7.2
  django-cms==3.4.4
  django-formtools>=1.0
  django-sekizai>=0.7
  django-treebeard>=4.0.1
  djangocms-admin-style>=1.0
  pytz

Finding the best candidates:
Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Could not find a version that matches django<1.11,==1.11.6,>=1.8
Tried: 1.1.3, 1.1.4, 1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6, 1.2.7, 1.3, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.3.5, 1.3.6, 1.3.7, 1.4, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.4.5, 1.4.6, 1.4.7, 1.4.8, 1.4.9, 1.4.10, 1.4.11, 1.4.12, 1.4.13, 1.4.14, 1.4.15, 1.4.16, 1.4.17, 1.4.18, 1.4.19, 1.4.20, 1.4.21, 1.4.22, 1.5, 1.5.1, 1.5.2, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.8, 1.5.9, 1.5.10, 1.5.11, 1.5.12, 1.5.12, 1.6, 1.6, 1.6.1, 1.6.1, 1.6.2, 1.6.2, 1.6.3, 1.6.3, 1.6.4, 1.6.4, 1.6.5, 1.6.5, 1.6.6, 1.6.6, 1.6.7, 1.6.7, 1.6.8, 1.6.8, 1.6.9, 1.6.9, 1.6.10, 1.6.10, 1.6.11, 1.6.11, 1.7, 1.7, 1.7.1, 1.7.1, 1.7.2, 1.7.2, 1.7.3, 1.7.3, 1.7.4, 1.7.4, 1.7.5, 1.7.5, 1.7.6, 1.7.6, 1.7.7, 1.7.7, 1.7.8, 1.7.8, 1.7.9, 1.7.9, 1.7.10, 1.7.10, 1.7.11, 1.7.11, 1.8a1, 1.8b1, 1.8b2, 1.8rc1, 1.8, 1.8, 1.8.1, 1.8.1, 1.8.2, 1.8.2, 1.8.3, 1.8.3, 1.8.4, 1.8.4, 1.8.5, 1.8.5, 1.8.6, 1.8.6, 1.8.7, 1.8.7, 1.8.8, 1.8.8, 1.8.9, 1.8.9, 1.8.10, 1.8.10, 1.8.11, 1.8.11, 1.8.12, 1.8.12, 1.8.13, 1.8.13, 1.8.14, 1.8.14, 1.8.15, 1.8.15, 1.8.16, 1.8.16, 1.8.17, 1.8.17, 1.8.18, 1.8.18, 1.9a1, 1.9b1, 1.9rc1, 1.9rc2, 1.9, 1.9, 1.9.1, 1.9.1, 1.9.2, 1.9.2, 1.9.3, 1.9.3, 1.9.4, 1.9.4, 1.9.5, 1.9.5, 1.9.6, 1.9.6, 1.9.7, 1.9.7, 1.9.8, 1.9.8, 1.9.9, 1.9.9, 1.9.10, 1.9.10, 1.9.11, 1.9.11, 1.9.12, 1.9.12, 1.9.13, 1.9.13, 1.10a1, 1.10a1, 1.10b1, 1.10b1, 1.10rc1, 1.10rc1, 1.10, 1.10, 1.10.1, 1.10.1, 1.10.2, 1.10.2, 1.10.3, 1.10.3, 1.10.4, 1.10.4, 1.10.5, 1.10.5, 1.10.6, 1.10.6, 1.10.7, 1.10.7, 1.10.8, 1.10.8, 1.11a1, 1.11b1, 1.11rc1, 1.11rc1, 1.11, 1.11, 1.11.1, 1.11.1, 1.11.2, 1.11.2, 1.11.3, 1.11.3, 1.11.4, 1.11.4, 1.11.5, 1.11.5, 1.11.6, 1.11.6

• في جولة حل واحدة ، اكتشفنا أنه يتعين علينا تثبيت django==* و django-cms==3.4.4 .
• نختار المرشح: django==1.11.6 ، django-cms==3.4.4 .
• نحصل على التبعيات (سأركز على الجزء المهم):
  
  
  
  • django-cms==3.4.4 يتطلب django<1.11,>=1.8
  
  
  • django يتطلب django==1.11.6 (هذا ليس صحيحًا ، django لا يتطلب نفسه! لا توجد حزمة تتطلب نفسها!)
  
  
• نقوم بدمج محدد التبعيات معًا:
  
  
  
  • نطلب الآن django <1.11,==1.11.6,>=1.8 (يمكنك أن ترى إلى أين يذهب هذا ...)
  
  
• تغيرت القيود ، وعودة إلى اختيار المرشح.
• حاول العثور على مرشح مقابل django وهو <1.11,==1.11.6,>=1.8 :
  
  
  
  • Could not find a version that matches django<1.11,==1.11.6,>=1.8 [...]
  
  

ما كان يجب أن يحدث (كما يحدث في pip-tools ، مع pip مصحح ، مع - إعادة البناء لمسح ذاكرة التخزين المؤقت):

• في جولة حل واحدة ، اكتشفنا أنه يتعين علينا تثبيت django==* و django-cms==3.4.4 .
• نختار المرشح: django==1.11.6 ، django-cms==3.4.4 .
• نحصل على التبعيات (سأركز على الجزء المهم):
  
  
  
  • django-cms==3.4.4 يتطلب django<1.11,>=1.8
  
  
  • django يتطلب pytz ، لكن ليس django==1.11.6
  
  
• نقوم بدمج محدد التبعيات معًا:
  
  
  
  • نطلب الآن django <1.11,>=1.8 (أفضل بكثير ...)
  
  
• تغيرت القيود ، وعودة إلى اختيار المرشح.
• حاول العثور على مرشح مقابل django وهو <1.11,>=1.8 :
  
  
  
  • اختيار مرشح جديد django ، من المحتمل django==1.10.8
  
  
• يحسب التبعيات ، ويستمر ويحل بسعادة.

ماذا تفعل من هنا؟

حسنًا ، إزالة self.requirements.values() من العائد في _prepare_file يصلح هذه المشكلة ، يمكنني تأكيدها. لسوء الحظ ، لم أحسب بالضبط سبب إضافته هناك.

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

وأعتقد أن كل شيء. ☕️

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

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

بالنظر إلى الكود ، أعتقد أن هذا يحاول حل وجود إعلان مثل requests[security] والذي قد يكون له تبعية certifi[some-extra] والتي تحتاج أيضًا إلى حل. هذا هو الشيء الوحيد الذي يمكنني التفكير فيه على الأقل. أراهن أن هناك شيئًا ما في عالم Django يقوم بهذا ، وإذا تمكنا من إيجاد مثال يتيح لنا كتابة اختبار.

وبالتالي! إذا رغب أي شخص في العمل على وضع هذه الاختبارات معًا ، والتأكد من الفشل الأول وعمل "التبعية العميقة" ، فيمكننا النظر في إزالة تصريح self.requirements.values() .

nateprewitt هذا شيء أعتقد أنه يصف ما تعنيه:
https://github.com/vphilippon/testdeepextra

ولكن ، "foo [a] يعتمد على bar [b]" الدقة العميقة تبدو جيدة بالفعل في pip-tools ، حيث يمكن اختبارها باستخدام هذا الريبو.
لذلك قد لا يكون هذا التصحيح بالضبط ، كما أفترض أنه لشيء لم يكن يعمل في الأصل في pip-tools . ما لم يكن في حالة معينة لم أتمكن من الاختبار هنا.

على أي حال ، لا يزال بإمكاننا اختبار سلوك حل إضافي pipenv مع هذا الريبو (الذي ليس لدي الوقت لفعله على الفور) ، مع هذا التصحيح وبدونه ، ومعرفة ما إذا كان له أي تأثير ، و / أو قارن مع ناتج pip-tools . على الأقل لدينا نقطة انطلاق.

Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Could not find a version that matches sanic-plugins-framework==0.5.0.dev20171225,>=0.5.0.dev20171225
Tried: 0.2.0.dev20171102, 0.2.0.dev20171102, 0.3.0.dev20171102, 0.3.0.dev20171102, 0.3.1.dev20171102, 0.3.1.dev20171102, 0.3.2.dev20171102, 0.3.2.dev20171102, 0.3.3.dev20171102, 0.3.3.dev20171102, 0.4.0.dev20171103, 0.4.0.dev20171103, 0.4.1.dev20171103, 0.4.1.dev20171103, 0.4.2.dev20171106, 0.4.2.dev20171106, 0.4.4.dev20171107, 0.4.4.dev20171107, 0.4.5.dev20171113, 0.4.5.dev20171113, 0.5.0.dev20171225, 0.5.0.dev20171225, 0.5.2.dev20180201, 0.5.2.dev20180201

1. حصلت على هذا الخطأ عندما يساوي إصدار الحزم '*' ， ولكن عندما أقوم بتغييره إلى الإصدار المعروف ، مثل '== 0.1.2' ، فإنه يعمل بشكل جيد.
2. للأسف ، عندما أكتب pipenv install sanic-plugins-framework==0.5.0.dev20171225 ، استعدت رسالة الخطأ الكبيرة هذه. ربما لا يكون كل الإصدار أعلاه أكبر من "0.5.0.dev20171225"
3. كيف علي أن أفعل لتغطية هذا

pipenv lock —pre —clear

شكرًا لك Jasonsey على مشاركة الشيء الخاص بك و techalchemy على إجابتك.
واجهت مشكلة على وجه التحديد مع sanic-plugins-framework ، وقد ساعدتني إضافة علامة --pre (_Allow قبل الإصدارات ._) في تثبيت الحزمة 🙌

هل تم إصلاح هذا من قبل؟ ما زلت أتلقى نفس السلوك الخاطئ.
https://github.com/pypa/pipfile/issues/114