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 स्पष्ट रूप से उपलब्ध विकल्पों में से एक है।

मैं https://github.com/kennethreitz/pipenv/issues/786 के कारण पिपेनव के किसी भी पुराने संस्करण में निर्भरता रिज़ॉल्यूशन का परीक्षण करने में असमर्थ हूं

एक ही मुद्दा - यह विशेष रूप से अनुरोधों के बारे में शिकायत कर रहा है।

यह एक बग है, जिसका मानना ​​है कि मैं @vphilippon की टिप्पणी से संबंधित

सटीक, # 909 से संबंधित नहीं है।
जैसा कि मैंने कहा, मुझे यह समझने के लिए @maintainers में से किसी एक से इनपुट की आवश्यकता होगी कि "गहरे एक्स्ट्रस को हल करने" का मतलब क्या है। मेरे पास एक फिक्स है, लेकिन मैं पहले कुछ भी नहीं तोड़ने के लिए और अधिक जानना चाहूंगा।

या मैं आगे बढ़ सकता था और फिक्स के साथ एक पीआर खोल सकता था और वहां चर्चा कर सकता था। मैं अपने खाली समय के साथ देखूंगा।

@vphilippon चूंकि यह एक संगठन में नहीं है, बल्कि केनेथ के लिए एक व्यक्तिगत रेपो है, इसलिए दुर्भाग्य से हम सभी को पाने के लिए एक आसान @ टैग नहीं है। मैं सिर्फ @erinxocon और खुद को पिंग करने का सुझाव दूंगा।

केनेथ के सिर में कहीं भी पैच करने के लिए पैच दुर्भाग्य से बंद है। मुझे नहीं लगता कि मुझे समझ में आया है, या यहां देखने का समय है, यहां क्या हो रहा है। यदि आपको लगता है कि आप क्या सोचते हैं, संकलन करने के लिए कुछ समय मिल जाएगा, तो मैं मान्यताओं को सत्यापित करने में मदद करने का प्रयास कर सकता हूं। तब तक, हालांकि, यह कुछ ऐसा है जिसे हमें बदलाव करने से पहले हल्के से चलना होगा।

@nateprewitt ऑलराइट , मैं जितना कर सकता हूं उतना

क्या गलत है?

Https://github.com/kennethreitz/pipenv/issues/875#issuecomment -335570812 में, मैंने त्रुटि का स्रोत नोट किया: एक हल करने वाले दौर में चयनित उम्मीदवारों को सीधे उम्मीदवार की पिन की हुई निर्भरता के रूप में जोड़ा जाता है, जो गलत है ( उस पर अधिक आ रहा है)

Https://github.com/kennethreitz/pipenv/issues/875#issuecomment -336609268 में, मुझे उस पिन का स्रोत मिला: self.requirements.values() जो रिटर्न वैल्यू में जोड़ा गया था, उसमें वर्तमान पैकेज में एक पिन शामिल है । दूसरे शब्द में, _prepare_file को पैकेज की निर्भरता लौटानी चाहिए (या "अतिरिक्त InstallRequirements की एक सूची भी स्थापित करने के लिए"), लेकिन अब इसमें स्वयं, अपनी खुद की निर्भरता के रूप में पिन किया हुआ शामिल है।

यह प्रदर्शित करने में मदद करने के लिए कि पैकेज को ही क्यों, अपने स्वयं के आश्रित के रूप में पिन किया गया है, वास्तव में गलत है, यहाँ बताया गया है कि कैसे निर्भरता को हल करने वाला एल्गोरिदम काम करता है, संक्षेप में:

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

लेकिन, "फू [ए] बार [बी] पर निर्भर करता है" गहरी संकल्प 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

अपने बिट साझा करने के लिए और आपके उत्तर के लिए @techalchemy करने के लिए आप @Jasonsey धन्यवाद।
मुझे विशेष रूप से sanic-plugins-framework समस्या थी, और --pre (_Allow पूर्व-रिलीज़._ ध्वज) को जोड़ने से मुझे पैकेज स्थापित करने में मदद मिली with

क्या यह कभी तय किया गया था? मुझे अब भी वही गलत व्यवहार मिल रहा है।
https://github.com/pypa/pipfile/issues/114