Pip: पाइप में `आयात पिप` के साथ त्रुटि 9.0.2

मैं इसकी पुष्टि भी कर सकता हूं। एक ही मामला दर्ज करने जा रहा है।

यह #5079 का एक डुप्ली है - पाइप आयात करना समर्थित उपयोग केस नहीं है (और कभी नहीं किया गया है)।

चलो.. एक x.x.PATCH संस्करण टक्कर में एक बड़ा ब्रेकिंग परिवर्तन कर रहे हैं? शीर्ष स्तर की विधि के लिए जिसे "मुख्य" कहा जाता है? मुझे लगता है कि यह काफी खराब फॉर्म है..

इसने एनाकोंडा को भी तोड़ दिया और मैं @Miserlou जैसा ही समाधान लेकर आया:

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

कई परियोजनाओं में खामियां बताई जा रही हैं।

इस त्रुटि ने मुझे तब भी परेशान किया जब मैं अपने एनाकोंडा-नेविगेटर को अद्यतन करने के लिए पाइप का उपयोग करने का प्रयास कर रहा था।

क्या हमारे पास 9.0.3 प्राप्त करने का कोई मौका है जो इसे ठीक करता है - आदर्श रूप से बहुत जल्द?

यह पहले से ही कई प्रमुख परियोजनाओं (एनाकोंडा, स्पासी, ज़प्पा) को प्रभावित कर रहा है, और अकेले गिटहब पर इसके 850k+ से अधिक उपयोग हैं जो अब इस "पैच" संस्करण अपडेट से टूट गए हैं।

क्या आप कम से कम 9.0.3 में इस बड़े बदलाव को वापस ला सकते हैं और फिर _announce_ को भविष्य में 10.xx या कम से कम 9.xx रिलीज के लिए इस व्यवहार को बदलने के अपने इरादे को डाउनस्ट्रीम में वापस कर सकते हैं?

हम पुराने संस्करण का भी उपयोग नहीं करना चाहते हैं, लेकिन ठीक यही हमने किया है। 9.0.2 हमारे सीआई वातावरण में मौजूद नहीं है, कम से कम अभी के लिए।

कुछ ओपनस्टैक परियोजनाओं में भी इस हिट को देखकर।

पिप 10 लगभग एक महीने में समाप्त होने वाला है। जैसा कि मैं इसे समझता हूं, मुद्दा कोड के साथ है जो पाइप की आंतरिक कार्यक्षमता तक पहुंचने के लिए import pip का उपयोग करता है। हमने कभी भी आधिकारिक तौर पर इस तरह के उपयोग का समर्थन नहीं किया है, और हमने स्पष्ट रूप से कुछ समय के लिए समर्थन की कमी को स्पष्ट रूप से प्रलेखित किया है (यद्यपि केवल https://pip.pypa.io/en/latest/user_guide पर डॉक्स के "नवीनतम" संस्करण में। /#use-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 अपडेट में आया, जो _चीजों को ठीक करने के लिए माना जाता है, उन्हें तोड़ने के लिए नहीं_। यह सिमेंटिक वर्जनिंग के बिल्कुल विपरीत है। और, परिणामस्वरूप, हम पायथन पारिस्थितिकी तंत्र में भारी क्षति देख रहे हैं।

आपको इस परिवर्तन ASAP को किसी अन्य PATCH अपडेट में वापस करना चाहिए, फिर प्रमुख ब्रेकिंग परिवर्तन MAJOR संस्करण अपडेट के साथ आना चाहिए। अब जबकि आपने समय से पहले ही सबके लिए सब कुछ तोड़ दिया है, मुझे लगता है कि वे अधिक जागरूक होंगे कि वास्तविक बड़ा बदलाव आ रहा है।

मुझे यह भी लगता है कि यह कहने के लिए एक पुलिस वाला है कि यह दस्तावेज किया गया था और पहले से ही घोषित किया गया था, क्योंकि यह स्थिर दस्तावेज़ीकरण में _not_ प्रलेखित था, और घोषणा में कहा गया था कि ब्रेक _ प्रमुख संस्करण के लिए होगा, एक पैच में एक महीने के लिए नहीं पूर्व।

कृपया, बस हर किसी को भारी सिरदर्द से बचाएं, इस समस्या को वापस लाएं और वास्तव में सिमेंटिक वर्जनिंग का पालन करना शुरू करें।

@Miserlou ठीक है, मैं आपकी बात लेता हूं - हमने पाइप 10 के लिए आंतरिक नामकरण परिवर्तन को लक्षित किया क्योंकि यह एक प्रमुख संस्करण है। मैं वास्तव में पैच रिलीज के लिए ड्राइवरों को नहीं जानता - @dstufft ने मुझे इसके बारे में पिंग किया और यह स्पष्ट रूप से मैक ओएस उपयोगकर्ताओं के लिए महत्वपूर्ण ब्रेकेज से बचने के लिए है जब टीएलएस समर्थन के लिए एक आसन्न समय सीमा हमें हिट करती है, जो कि पीआईपी 10 रिलीज से पहले है। हमें उम्मीद थी कि समस्याएँ इतनी महत्वपूर्ण होंगी कि एक अल्पकालिक पैच रिलीज़ की गारंटी दे सकें। निश्चित रूप से मौजूदा उपयोग को तोड़ने का कोई इरादा नहीं था।

मुझे 9.0.3 पर अनुवर्ती कार्रवाई का निर्णय @dstufft पर छोड़ना होगा - मेरे पास इस बात का विवरण नहीं है कि 9.0.2 में क्या हुआ या यह जानना संभव है कि इस मुद्दे को कैसे ठीक किया जाए, इसकी पहचान करना संभव है। और मैं यह नहीं आंक सकता कि 9.0.2 को पूरी तरह से खींचना एक समग्र लाभ होगा, क्योंकि मुझे नहीं पता कि मैक ओएस मुद्दे से कितने लोग प्रभावित हैं। मैं समझता हूं कि (कम से कम कुछ लोगों के लिए) 9.0.1 पर पिन करना एक समाधान है, जिससे कि कम से कम खराब विकल्प हो सकता है।

macOS TLS समस्या macOS पर सिस्टम पायथन का उपयोग करने वाले सभी लोगों को प्रभावित करेगी<10.13

मुझे फॉलो-अप 9.0.3 का निर्णय @dstufft . पर छोड़ना होगा

मैं @pfmoore जैसी ही स्थिति का हूं।

समाधान, यदि आपके पास यह आपके लिए उपलब्ध है, तो आयात के क्रम की जांच करना और अन्य पैकेज आयातों के ऊपर आयात करने वाले पाइप का परीक्षण करना है (विशेष रूप से, pip _before_ आयात करने के अनुरोध कुछ मामलों को हल करने के लिए लगता है)। (ध्यान दें कि यह अभी भी पाइप के आंतरिक उपयोग का तात्पर्य है, जो आधिकारिक तौर पर समर्थित नहीं है।)

एक ही मुद्दा यहाँ पिप 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'

FYI करें, 9.0.2 को टूटे हुए निर्माण के साथ जारी किया गया था:

ट्रैविस-सीआई संदर्भ: https://travis-ci.org/pypa/pip/builds/354616774?utm_source=github_status&utm_medium=notification

दी गई त्रुटियां असंबंधित हो सकती हैं, हालांकि यह सिर्फ "जल्दी रिलीज" की तरह गंध करता है ...

@pfmoore

अगर @dstufft एक आपातकालीन 9.0.3 रिलीज़ करना चाहता है, तो मैं इसके साथ ठीक हूँ। लेकिन यह केवल एक बहुत ही अल्पकालिक लाभ होगा, और मैं थोड़ा निराश हूं कि लोग पहले से ही आयात पाइप से दूर नहीं हुए हैं। इस समस्या से प्रभावित लोगों को अभी भी पिप 10 के लिए तैयारी करने की आवश्यकता होगी, और उन्हें यह समझना चाहिए कि केवल आयात pip._internal पर स्विच करना कोई ऐसी चीज नहीं है जिसका हम समर्थन करेंगे या अनुशंसा करेंगे।

मुझे विश्वास नहीं हो रहा है कि यह इस रिपॉजिटरी के मालिक का एक बयान है... आपने शाब्दिक रूप से "f*ck सिमेंटिक वर्जनिंग" और "जिसे किसी भी तरह से बहिष्करण नीति की आवश्यकता है" कहा है।

पाइप हमेशा एक उपभोज्य अजगर एपीआई नहीं होने के रूप में प्रलेखित किया गया था, मैं लोगों में निराश हूं कि उस बिंदु पर भी "कुछ वर्षों से आपको ऐसा बताया" कर्म को चालू करने का प्रयास करें

@RonnyPfannschmidt यह कहने जैसा है "हमने आपको 100 बार कहा है कि आपको गति सीमा से अधिक ड्राइव करने की अनुमति नहीं है" और फिर सभी इंजन-कारों को फ्लिंटस्टोन-कारों के साथ बदलकर गति सीमा लागू करना, ताकि लोग आगे न जा सकें अब गति सीमा।

आपने अभी पूरी तरह से प्रदर्शित किया है कि शब्दों को बदलना इतना बुरा है - कह रहा था "इस पर भरोसा मत करो यह टूट जाएगा" - अब यह टूट गया और अचानक जिस परियोजना ने आपको बताया कि वह टूट जाएगी, गलती है

यह सिर्फ इसलिए दोष देना है क्योंकि आप गलती करना पसंद नहीं करते हैं

@RonnyPfannschmidt

यह सिर्फ इसलिए दोष देना है क्योंकि आप गलती करना पसंद नहीं करते हैं

तो आप कह रहे हैं कि मैं तीसरे पक्ष के पैकेज का उपयोग करने के लिए गलती कर रहा हूं जो पीआईपी की एक अनिर्दिष्ट सुविधा पर निर्भर करता है। हो सकता है, मैं हूं... मुझे उन त्रुटियों के लिए उन तृतीय-पक्ष पैकेजों की जांच करनी चाहिए थी और एक मुद्दा या उससे भी बेहतर पीआर प्रस्तुत करना चाहिए था।

लेकिन आइए वास्तविकता का सामना करें: वहाँ बहुत सारी परियोजनाएँ हैं जो उत्पादन में उपयोग की जाती हैं जो अब टूट चुकी हैं। यह नैतिकता का सवाल नहीं है, यह किसकी गलती है, इसका सवाल नहीं है। यह "क्या आप कृपया इसे ठीक कर सकते हैं और उचित चेतावनी/बहिष्कार प्रदान कर सकते हैं" का मामला है।

यदि कोई तृतीय-पक्ष पैकेज आप ब्रेक का उपयोग करते हैं क्योंकि यह अनियंत्रित, गैर-गारंटीकृत आंतरिक एपीआई पर निर्भर करता है, तो मुझे ऐसा लगता है कि आपको उस पैकेज के खिलाफ एक बग दर्ज करना चाहिए।

pip के कौन से हिस्से हैं और तीसरे पक्ष के उपभोग के लिए अभिप्रेत नहीं हैं, के बीच एक आसान-से-खोज रेखा है, और मैं इसके डेवलपर्स को आंतरिक एपीआई बनाए रखने के लिए मजबूर करने की कोशिश का समर्थन नहीं करता जो कभी नहीं होना चाहिए था तृतीय-पक्ष पैकेज द्वारा उपभोग किया गया। मैं इसे pip डेवलपर्स की गलती मानने और नाराज उपयोगकर्ताओं को उनके रास्ते भेजने का समर्थन नहीं करता। यदि आप किसी पर क्रोधित होना चाहते हैं, तो अपने द्वारा उपयोग किए जाने वाले किसी भी पैकेज पर क्रोधित हों, जो आंतरिक एपीआई पर निर्भर करता है, और अपने अनुरक्षकों को अपना कोड ठीक करने के लिए प्रेरित करता है।

@anx-ckreuzberger

मुझे विश्वास नहीं हो रहा है कि यह इस रिपॉजिटरी के मालिक का एक बयान है... आपने शाब्दिक रूप से "f*ck सिमेंटिक वर्जनिंग" और "जिसे किसी भी तरह से बहिष्करण नीति की आवश्यकता है" कहा है।

जबकि मैं यहां की हताशा को समझता हूं, मैं लोगों की उन चीजों के लिए पाइप अनुरक्षकों को दोष देने की इच्छा से नाराज हो रहा हूं, जिनका हमने कभी वादा नहीं किया था।

अगर आप इस तरह के आरोप लगाना चाहते हैं, तो कृपया उनका समर्थन करें

1. किसी भी पाइप अनुरक्षक के एक बयान के लिए एक सूचक कि हम उपयोगकर्ता कोड में पाइप आंतरिक एपीआई के उपयोग का समर्थन करते हैं।
2. किसी भी पाइप अनुरक्षक के बयान के लिए एक सूचक जो कि पाइप सिमेंटिक वर्जनिंग का उपयोग करता है।

मुझे नहीं लगता कि आपको वो सबूत मिलेंगे...

तो आप कह रहे हैं कि मैं तीसरे पक्ष के पैकेज का उपयोग करने के लिए गलती कर रहा हूं जो पीआईपी की एक अनिर्दिष्ट सुविधा पर निर्भर करता है।

नहीं, लेकिन उन परियोजनाओं के बजाय पाइप अनुरक्षकों पर आरोप लगाना स्वीकार्य नहीं है। हम आपकी मदद करने की कोशिश कर रहे हैं लेकिन उन परियोजनाओं के लिए जिम्मेदार नहीं ठहराया जा सकता है। उनके साथ अपनी शिकायतों को हवा दें।

लेकिन आइए वास्तविकता का सामना करें: वहाँ बहुत सारी परियोजनाएँ हैं जो उत्पादन में उपयोग की जाती हैं जो अब टूट चुकी हैं। यह नैतिकता का सवाल नहीं है, यह किसकी गलती है, इसका सवाल नहीं है। यह "क्या आप कृपया इसे ठीक कर सकते हैं और उचित चेतावनी/बहिष्कार प्रदान कर सकते हैं" का मामला है।

हमने चेतावनी देने की कोशिश की। हमने महीनों पहले घोषणाएं भेजीं, हमने स्थिति की व्याख्या करने वाले दस्तावेज़ जोड़े, और हमने लगातार ट्रैकर पर समस्याओं का जवाब दिया है जिसमें कहा गया है कि आंतरिक एपीआई का उपयोग असमर्थित है। बहिष्करण जोड़ना उतना आसान नहीं है जितना आप सुझाव देते हैं, क्योंकि पाइप स्वयं उन चेतावनियों को उगल देगा (या उन्हें बंद करने के लिए पाइप के लिए एक तरीका होगा, जिसे अन्य लोग कॉपी करेंगे - हम पहले से ही योजना बनाने वाले लोगों की सुन रहे हैं pip._internal आयात करें, इसलिए वह परिवर्तन भी उन्हें नहीं रोकेगा: निराश :)।

जहां तक ​​इसे "ठीक" करने का सवाल है, मैं खुशी-खुशी स्वीकार करूंगा कि 9.0.2 को एक गंभीर समस्या का समाधान करने के लिए जल्दी से जारी किया गया था, और हमें इस समस्या का अनुमान नहीं था। हो सकता है कि 2-3 सप्ताह के जीवनकाल के साथ 9.0.3 जारी करना एक उचित बात हो, मुझे खुद ऐसा नहीं लगता, लेकिन मैंने कहा है कि हम इस पर विचार करेंगे। मैं इसे करने के लिए व्यक्तिगत रूप से सहमत नहीं हो सकता, क्योंकि मैं 9.0.x रिलीज में शामिल नहीं हूं। मैं पिप 10 पर काम कर रहा हूं, जो इस सारी बहस को अप्रासंगिक बना देगा, इसलिए इस मुद्दे पर शायद यह मेरा आखिरी शब्द है - मुझे उस रिलीज से संबंधित चीजों पर ध्यान देने की जरूरत है।

मेरी व्यक्तिगत सलाह:

1. यदि आप इससे प्रभावित हैं और अभी समाधान की आवश्यकता है, तो 9.0.1 पर पिन करें।
2. पाइप 10 के लिए तैयार रहें, जब आपके पास वर्तमान में मौजूद सभी निर्भरताएं टूट गई हैं क्योंकि वे पाइप आंतरिक एपीआई का उपयोग करते हैं, फिर से टूट जाएंगे। उन निर्भरताओं को उस जानकारी पर कार्रवाई करने के लिए प्रेरित करें जो हम महीनों से दे रहे हैं, और खुशी है कि आपको अग्रिम चेतावनी मिली है कि ऐसा होगा।
3. यदि पिप 9.0.3 रिलीज हो जाता है, तो पिन हटा दें।
4. कृपया , पीआईपी 10 बीटा का परीक्षण करें, जब यह बाहर आता है, और संबंधित पक्षों को किसी भी मुद्दे की रिपोर्ट करें (तृतीय पक्ष परियोजनाएं यदि वे आंतरिक रूप से पाइप को कॉल कर रहे हैं, तो हमें यदि आप स्वयं पाइप को कॉल कर रहे हैं)।

मैंने डॉक कंटेनर के भीतर पाइप 9.0.2 और पायथन 2.7.14 के साथ एक ही समस्या का अनुभव किया है।
हालांकि मैं एक डॉकटर कंटेनर के बाहर अपनी देव मशीन पर समस्या को पुन: उत्पन्न नहीं कर सकता।
मैंने एक पाइप आयात की खोज की ( import.pip , from.pip , \'pip , \"pip के लिए grep'd) लेकिन कुछ भी नहीं मिला।
हम प्लोन में एक सेटअप टूल setup.py फ़ाइल में शामिल संकुल से कॉन्फ़िगरेशन को स्वचालित रूप से शामिल करने के लिए एक तंत्र का उपयोग कर रहे हैं, जो संदिग्ध लगता है - लेकिन फिर से - यह केवल __import__ का उपयोग कर रहा है और पीआईपी AFAIcansee से नहीं।

यह ट्रेसबैक का प्रासंगिक हिस्सा है:

  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'

जहां तक ​​​​मैं समझता हूं कि केवल पाइप आयात करना - इसका उपयोग किए बिना - पहले से ही टूट जाता है। यह पायथन भूमि में एक अच्छा नागरिक व्यवहार नहीं है। इसका उपयोग करने का समर्थन नहीं करना/सार्वजनिक एपीआई प्रदान नहीं करना एक बात है, बस एक और आयात पर तोड़ना। यह बहुत सारे ऑटो-निरीक्षण कोड को प्रभावित करता है।

इसे इस तरह से सोचें: पाइप एक कमांड लाइन उपयोगिता है, पुस्तकालय नहीं। यह तथ्य कि यह पायथन में लिखा गया है, अप्रासंगिक है। यही है मामले की हकीकत।

@pfmoore

जबकि मैं यहां की हताशा को समझता हूं, मैं लोगों की उन चीजों के लिए पाइप अनुरक्षकों को दोष देने की इच्छा से नाराज हो रहा हूं, जिनका हमने कभी वादा नहीं किया था।

इसे इस तरह से सोचें: पाइप एक कमांड लाइन उपयोगिता है, पुस्तकालय नहीं। यह तथ्य कि यह पायथन में लिखा गया है, अप्रासंगिक है। यही है मामले की हकीकत।

लब्बोलुआब यह है कि इससे कोई फर्क नहीं पड़ता कि आपने क्या वादा किया था। महत्वपूर्ण यह है कि आपने क्या किया और परिणामी स्थिति क्या है। हो सकता है कि आपने इसे कमांड लाइन उपयोगिता के रूप में सोचा हो। लेकिन आपने इसे एक पुस्तकालय के रूप में जारी किया। ये है मामले की हकीकत:

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

तुम्हें क्या लगता है कि आगे क्या होगा?

अल्पावधि में, लोग पुराने संस्करण को केवल पिन करेंगे और जब तक कोई अच्छा कारण न हो, उसे अनपिन नहीं करेंगे।

लंबी अवधि में... ठीक है, यह इस बात पर निर्भर करता है कि कितने लोग तय करते हैं कि आपके द्वारा तोड़ी गई हर चीज को ठीक करने की तुलना में आपको प्रतिस्थापित करना अधिक लागत प्रभावी होगा।

@pfmoore क्या आप ऊपर उल्लिखित ट्रेसबैक में कुछ संदिग्ध देखते हैं? किसी भी पाइप आंतरिक AFAIK का कोई उपयोग नहीं है। यह दिलचस्प है कि ज्यादातर लोगों को डॉकटर कंटेनरों में यह समस्या होती है।

@ सभी, टूटे हुए कोड के लिए अनुरक्षकों पर आरोप लगाने से समस्या को हल करने में मदद नहीं मिलती है।

इसे इस तरह से सोचें: पाइप एक कमांड लाइन उपयोगिता है, पुस्तकालय नहीं। यह तथ्य कि यह पायथन में लिखा गया है, अप्रासंगिक है। यही है मामले की हकीकत।

तथ्य: इसे आयात नहीं किया जा सकता है, अगर किसी कारण से ऑटो-निरीक्षण कोड द्वारा भी आयात किया जाता है: सभी ब्रेक। मुझे लगता है कि यह @thet के मामले में होता है।
निष्कर्ष: पाइप को वैश्विक या वर्तमान वर्चुअलएन्व/वेनव पायथन नेमस्पेस से खुद को अलग करना चाहिए जिसमें यह पैकेज स्थापित करता है। इस तरह यह इसे प्रदूषित नहीं करता है और यहां तक ​​कि दुर्घटनावश आयात भी नहीं होता है।

सबसे पहले, क्षमा करें यदि मैंने रेपो के अनुरक्षकों पर दोषपूर्ण कोड का आरोप लगाया है। किसी भी आरोप को हताशा से बाहर किया गया था, और, यदि बिल्कुल भी, इस तथ्य की ओर इशारा करते हैं कि IMHO 9.0.2 रिलीज सेवर की परिभाषा के अनुसार एक पैच रिलीज है (हालांकि @pfmoore ने यह स्पष्ट किया कि पाइप जरूरी नहीं कि सेवर का उपयोग कर रहा हो - जो मुझे लगता है कि एक और दिन के लिए एक और मुद्दा है)।

@ माइकहार्ट85

अल्पावधि में, लोग पुराने संस्करण को केवल पिन करेंगे और जब तक कोई अच्छा कारण न हो, उसे अनपिन नहीं करेंगे।
लंबी अवधि में... ठीक है, यह इस बात पर निर्भर करता है कि कितने लोग तय करते हैं कि आपके द्वारा तोड़ी गई हर चीज को ठीक करने की तुलना में आपको प्रतिस्थापित करना अधिक लागत प्रभावी होगा।

बहुत ज्यादा। मेरा मतलब है कि जावास्क्रिप्ट पैकेज मैनेजर देखें: एनपीएम, बोवर, यार्न, जो कुछ भी अगले ~ वर्ष ~ सप्ताह जारी किया जाता है

नहीं, लेकिन उन परियोजनाओं के बजाय पाइप अनुरक्षकों पर आरोप लगाना स्वीकार्य नहीं है। हम आपकी मदद करने की कोशिश कर रहे हैं लेकिन उन परियोजनाओं के लिए जिम्मेदार नहीं ठहराया जा सकता है। उनके साथ अपनी शिकायतों को हवा दें।

मैं समझता हूं कि इस मुद्दे में मेरी (हमारी?) शिकायतों को गलत दिशा में ले जाया जा सकता है। यद्यपि आपको यह स्वीकार करना होगा कि किसी को भी यह विश्वास दिलाना वास्तव में कठिन है कि यह तृतीय-पक्ष-रखरखावकर्ताओं की गलती है।

हमने चेतावनी देने की कोशिश की। हमने महीनों पहले घोषणाएं भेजीं, हमने स्थिति समझाते हुए दस्तावेज़ जोड़े

क्या यह पिप 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) और जारी होने के बाद से अब तक PyPI से 17 मिलियन फ़ाइलें डाउनलोड कर चुका है। अंतिम दिन को देखते हुए , यह पाइप 9.0.1 से आगे निकलने का 80% तरीका है, जो कि PyPI पर सबसे अधिक उपयोग किए जाने वाले इंस्टॉलर के रूप में है।

इसलिए जब मैं मानता हूं कि इसने कुछ लोगों के लिए चीजें तोड़ दीं, तो यह अपेक्षाकृत कम संख्या में लोग हैं जो या तो असमर्थित चीजें कर रहे हैं, या काफी हद तक मामले की स्थिति में हैं।

अगर मुझे समय मिल जाए, तो मैं 9.0.3 काटने की कोशिश कर सकता हूं, मुख्य रूप से उस मामले को हल करने के लिए जो @thet चला गया है जहां यह सिर्फ एक ऑटो-आयातक है जो चीजों को आयात करने की कोशिश कर रहा है, और वे वास्तव में उपयोग करने का प्रयास नहीं कर रहे हैं पिप के आंतरिक एपीआई किसी भी तरह से। अगर वह भी पाइप के आंतरिक एपीआई का उपयोग करने वाले लोगों के व्यवहार को हल करता है, तो मैं उन्हें विशेष रूप से तोड़ने के लिए अपने रास्ते से बाहर नहीं जा रहा हूं, लेकिन अगर ऐसा नहीं होता है तो मैं भी ठीक करने के लिए अपने रास्ते से बाहर नहीं जा रहा हूं उन्हें विशेष रूप से या तो।

कृपया ध्यान दें कि इस बिंदु पर 9.0.x जारी करने में कई घंटे लगते हैं (चीजें master में इतनी अलग हो गई हैं कि इसे रिलीज करने के लिए कुछ अंतिमकरण की आवश्यकता है) और यह डीबग करने के लिए आवश्यक समय की गणना नहीं करता है और वास्तविक मुद्दे को ठीक करें। यदि आप ऐसा होने की संभावना को बढ़ाना चाहते हैं, तो डिबगिंग और फिक्सिंग करना और पैच प्रदान करना (या अपने स्वयं के कांटे में 9.0.2 टैग से एक शाखा बंद) ऐसा करने का सबसे अच्छा तरीका है।

सबसे पहले, क्षमा करें यदि मैंने रेपो के अनुरक्षकों पर दोषपूर्ण कोड का आरोप लगाया है। कोई भी आरोप हताशा में लगाया गया था

शुक्रिया। यहाँ निराशा बहुत अधिक है, और मैं इसे समझता हूँ।

बस एक और जोड़ने के बारे में कैसे?

अच्छा विचार - काश हमने कुछ समय पहले इस बारे में सोचा होता। बेशक, अब कोई वास्तविक बिंदु नहीं है, क्योंकि आंतरिक नामस्थान को पाइप 10 में पुनर्गठित किया जाएगा, इसलिए बहुत देर हो चुकी है। यह ट्रिक मुझे भविष्य के लिए जरूर याद रहेगी।

क्या यह पिप 9.0.2 के लिए या पिप 10 के लिए था?

10.0 के लिए। 9.0.2 जारी करने का कोई मूल इरादा नहीं था, हमने केवल एक आपातकालीन रिलीज के रूप में ऐसा किया ताकि मैक ओएस के उपयोगकर्ता टीएलएस परिवर्तन प्रभावी होने पर पीईपीआई तक सभी पहुंच खो न दें।

@dstufft ने यहां और अधिक पूरी तरह से प्रतिक्रिया दी है, इसलिए मुझे लगता है कि यह उतना ही हल हो गया है जितना अभी के लिए होने की संभावना है।

मुझे यह "खतरा" हमेशा मनोरंजक लगता है।

यह बिल्कुल भी खतरा नहीं है, अगर यह इस तरह से आया हो तो क्षमा करें।

यह किसी ऐसी चीज़ के बारे में एक अवलोकन है जो सॉफ़्टवेयर की दुनिया में अक्सर होता है। लोग आपके वादों या इरादों के साथ काम नहीं करते हैं। लोग आपके द्वारा डिलीवर किए जाने वाले उत्पाद के साथ काम करते हैं। यदि आपके उत्पाद में ऐसी विशेषता है जिस पर बहुत से लोग निर्भर हैं, तो आप इसे केवल उनके पैरों के नीचे से नहीं निकाल सकते। यदि आप करते हैं, तो वे आपके उत्पाद को टूटा हुआ देखने लगते हैं। यदि आपके द्वारा प्रदान किया जाने वाला एकमात्र स्पष्टीकरण "ठीक है, हमने कभी भी इसका वादा नहीं किया" तो वे अपनी चिंताओं को एक दायित्व के रूप में स्वीकार करने की आपकी अनिच्छा को देखना शुरू कर देते हैं।

ऐसा जितना अधिक होता है, विकल्प की इच्छा और मांग उतनी ही अधिक होती है। ज़रूर, लोग इस बात को कम आंकते हैं कि इसमें कितना काम लगता है। लेकिन यह केवल उन्हें अधिक बनाता है, कम नहीं, एक पर काम करना शुरू करने की संभावना। एक बार जब वह गेंद लुढ़क जाती है, तो उसका अपना जीवन होता है।

विकल्प हमेशा अच्छी चीज नहीं होते हैं। वे चीजों को गन्दा करने के लिए प्रवृत्त होते हैं। व्यक्तिगत रूप से, मैं एकल पैकेज प्रबंधक को प्राथमिकता दूंगा। प्रत्येक वस्तु के लिए। लेकिन मैं पायथन के लिए एकल पैकेज प्रबंधक के लिए समझौता करूंगा।

जब लोग रिपोर्ट करते हैं कि आपने किसी सुविधा को तोड़ दिया है, इरादा या अन्यथा, तो संक्षेप में यह समझाने पर विचार करें कि आपको इसे क्यों तोड़ना पड़ा, या इसे क्यों रखना व्यवहार्य नहीं था, बजाय "यह सभी के साथ समर्थित नहीं था" के साथ चिंताओं को खारिज करने के बजाय।

अरे @dstufft , इसमें शामिल होने के लिए धन्यवाद। यह धागा बहुत गर्म हो रहा है!

सबसे पहले, मैं आपके काम के लिए धन्यवाद देता हूं! मुझे पता है कि रखरखाव एक अंतहीन, धन्यवाद रहित कार्य है, और मुझे लगता है कि यह केवल तभी खराब हो जाता है जब आप pip के रूप में बड़े और लोकप्रिय प्रोजेक्ट का प्रबंधन करते हैं!

अब, मौजूदा मुद्दे पर: हालांकि अब तक बीस रखरखावकर्ताओं ने इस समस्या की सूचना दी है, मुझे पता है कि यह पहले से ही हजारों लोगों को प्रभावित कर रहा है - प्रभावित परियोजनाओं में से कुछ अपने आप में बड़े पैमाने पर हैं: एनाकोंडा, ओपनस्टैक, स्पासी, ज़प्पा, और है कई दसियों हज़ारों उपयोगकर्ता। मुझे पता है कि हमारा स्लैक चैनल इस बारे में चर्चाओं से भरा हुआ है। (सचमुच, जैसा कि मैं इसे लिख रहा था, एक नया मुद्दा सामने आया।)

स्पष्ट रूप से, कई महत्वपूर्ण पायथन परियोजनाएं हैं जिन्हें प्रोग्रामेटिक रूप से अपने वातावरण का निरीक्षण करने की क्षमता की आवश्यकता होती है। ऐसा करने में सक्षम होने के लिए यह पूरी तरह से उचित बात है। इसके अलावा, प्रलेखन ने ऐसा करने के खिलाफ कभी चेतावनी नहीं दी - और अभी भी नहीं करता है! (इस रेपो के README से डॉक्स लिंक पर क्लिक करें!)

मुझे लगता है कि अब तक की स्थिति है:

• संस्करण स्ट्रिंग के प्रारूप को देखते हुए, हम सभी मानते हैं कि पाइप अनुरक्षक सिमेंटिक वर्जनिंग का अनुसरण कर रहे हैं
• पाइप अनुरक्षकों ने एक "पैच" जारी किया जिसने व्यापक रूप से तोड़ने वाले परिवर्तन की शुरुआत की
• यह परिवर्तन अघोषित और अनिर्दिष्ट था - और मुझे लगता है, अप्रत्याशित और अनपेक्षित
• अब, केवल import pip को कॉल करने से प्रोग्राम तुरंत टूट जाता है, जो कि अत्यधिक डेवलपर-शत्रुतापूर्ण है
• यह पायथन पारिस्थितिकी तंत्र में प्रमुख सिरदर्द पैदा कर रहा है
• दस्तावेज़ीकरण नहीं करता है (और _still_ नहीं करता है - इस रेपो के रीडमे में डॉक्स लिंक पर क्लिक करें) प्रोग्रामेटिक रूप से pip का उपयोग करने के खिलाफ चेतावनी देता है।
• ऐसी कोई घोषणा नहीं की गई थी कि import pip PATCH अपडेट में इस नुकसान का कारण बनेगी - यह घोषणा एक ऐसे संस्करण के लिए आई है जो _अभी तक जारी नहीं किया गया है।
• चेंजलॉग में इस बदलाव का जिक्र तक नहीं किया गया था
• हम पाइप या पिप डेवलपर्स को बदलना नहीं चाहते हैं! हम तुमसे प्यार करते हैं!
• ..लेकिन हम नहीं चाहते कि इस तरह की घटना दोबारा हो!
• ..इसलिए हम चाहते हैं कि सेवर का पालन किया जाए!
• हम वास्तव में, वास्तव में एक और PATCH पसंद करेंगे जो इस बड़े ब्रेकिंग परिवर्तन को पूर्ववत करता है!

एक पाइप में एक पर्यावरण का निरीक्षण करने के लिए प्रोग्रामेटिक तरीके की आवश्यकता> = 10.0.0 दुनिया एक और चर्चा का विषय है, लेकिन इस मामले का तथ्य यह है कि हमें कभी नहीं बताया गया था कि हमें पाइप में प्रोग्रामेटिक रूप से पाइप का उपयोग नहीं करना चाहिए। <=9 दुनिया, और एक बड़े पैमाने पर, अघोषित परिवर्तन था, और हम वास्तव में इसे उलटा देखना चाहेंगे क्योंकि यह हजारों लोगों को नकारात्मक रूप से प्रभावित कर रहा है।

एक बार फिर धन्यवाद,
धनी

सबसे पहले: पिप अनुरक्षकों को उनके प्रयासों और परियोजना के भीतर अंतर्दृष्टि के लिए धन्यवाद। मेरा मानना ​​​​है कि यह वास्तव में दूसरों को इस मुद्दे को समझने में मदद करता है (हालांकि इसके बारे में एक सारांश ब्लॉग लेख लिखना उचित हो सकता है)।

@dstufft

इन चीजों के बारे में नजरिया रखना जरूरी है। वहाँ हैं .. 15 से कम? 20? लोग इस बारे में टिप्पणी कर रहे हैं कि इसने उन्हें कैसे तोड़ा (हालांकि इन मेट्रिक्स के साथ हमेशा "हिमशैल की नोक" समस्या होती है), इस बीच पाइप 9.0.2 पहले से ही पिछले सप्ताह में दूसरा सबसे अधिक उपयोग किया जाने वाला इंस्टॉलर है (दिनों की गिनती यह भी अस्तित्व में नहीं है) for) और जारी होने के बाद से अब तक PyPI से 17 मिलियन फ़ाइलें डाउनलोड कर चुका है। अंतिम दिन को देखते हुए, यह पाइप 9.0.1 से आगे निकलने का 80% तरीका है, जो कि PyPI पर सबसे अधिक उपयोग किए जाने वाले इंस्टॉलर के रूप में है।

मुझे पूरा यकीन है कि कॉन्टिनस इंटीग्रेशन/डिलीवरी सिस्टम से सभी स्वचालित pip install pip --upgrade कमांड द्वारा मीट्रिक भारी पक्षपाती है (उन्हें कैश का उपयोग करना चाहिए, और इसलिए हर समय pypi से पैकेजों को फिर से स्थापित करने की आवश्यकता नहीं है; लेकिन पर उसी समय, किसी को भी import pip नहीं करना चाहिए ... आईटी की दुनिया ऐसे ही काम करती है)।

तथ्य यह है कि (कम से कम) 15 लोगों ने इसके बारे में शिकायत की है, दो बातें बताना चाहिए:

1. मुझे नहीं लगता कि बहुत से लोग 9.0.2 (उत्पादन में) का उपयोग करते हैं, कुछ अभी भी इस मुद्दे को डीबग करने का प्रयास कर रहे हैं और इसे "अस्थायी रूप से" पीआईपी 9.0.1 का उपयोग करके ठीक कर देंगे जब तक कि इसे हल नहीं किया जाता है (या हमेशा के लिए .. .) - साथ ही, कुछ लोगों ने ध्यान नहीं दिया होगा कि अभी कुछ काम नहीं कर रहा है...
2. रिलीज के 2 दिन के अंदर ही लोग इसके बारे में बात कर रहे हैं. अधिक लोग इस समस्या का अनुभव करेंगे। 2 सप्ताह तक प्रतीक्षा करें, और आप 100 लोगों को इसके बारे में शिकायत कर सकते हैं (उदाहरण के लिए, जब वे स्प्रिंट खत्म करते हैं और क्यूए/स्टेजिंग पर तैनात होते हैं)। इस समय आप वास्तव में नहीं जानते कि इस परिवर्तन से कितने लोग प्रभावित होंगे।

वैसे भी, इस मुद्दे के बारे में बात करना और बहस करना लोगों को एक अच्छा उदाहरण देता है कि किसी को आंतरिक एपीआई पर भरोसा क्यों नहीं करना चाहिए, और उम्मीद है कि कुछ तृतीय-पक्ष पैकेज अनुरक्षक अपनी परियोजनाओं को अपडेट करेंगे क्योंकि यहां बात की गई है।

स्पष्ट रूप से, कई महत्वपूर्ण पायथन परियोजनाएं हैं जिन्हें प्रोग्रामेटिक रूप से अपने वातावरण का निरीक्षण करने की क्षमता की आवश्यकता होती है। ऐसा करने में सक्षम होने के लिए यह पूरी तरह से उचित बात है। इसके अलावा, प्रलेखन ने ऐसा करने के खिलाफ कभी चेतावनी नहीं दी - और अभी भी नहीं! (इस रेपो के README से डॉक्स लिंक पर क्लिक करें!)

यह मेरे लिए स्पष्ट नहीं है कि आपको इसके खिलाफ चेतावनी क्यों देनी होगी। कमांड लाइन टूल के अलावा किसी अन्य चीज़ के रूप में pip का उपयोग पूरी तरह से अनिर्दिष्ट है। प्रलेखन की खोज में मुझे पाइप आयात करने का कोई संदर्भ नहीं दिख रहा है । यह शिकायत करने जैसा है क्योंकि आपने क्रोम द्वारा उपयोग किए गए कुछ .so के खिलाफ लिंक किया और उन्होंने एबीआई संगतता को तोड़ दिया।

SemVer की सामान्य व्याख्या यह है कि यह समर्थित , सार्वजनिक इंटरफ़ेस (इस मामले में, CLI) पर लागू होता है, अनिर्दिष्ट इंटर्नल पर नहीं। आंतरिक का उपयोग करने वाले किसी भी व्यक्ति को अपने pip संस्करणों को वैसे भी पिन करना चाहिए, क्योंकि वे मनमाने परिवर्तन के अधीन हैं।

वास्तव में उलटने के लिए कुछ भी नहीं है। मैकोज़ पर उपयोगकर्ताओं के एक महत्वपूर्ण हिस्से को निकट भविष्य में पीईपीआई तक पहुंचने में असमर्थ होने से रोकने के लिए बैकपोर्टिंग फिक्स में 9.0.x कोड बेस पर लागू होने पर एक बग होता है जो केवल असमर्थित स्थितियों के तहत खुद को व्यक्त करता है। आगे का एकमात्र रास्ता 9.0.x श्रृंखला में उस बग को हल करने के लिए अतिरिक्त कार्य करना है। जैसे मैंने कहा कि अगर मुझे समय मिल गया तो मैं इसे करने की कोशिश करूंगा, अगर आप ऐसा होने की संभावना बढ़ाना चाहते हैं तो एक पैच प्रदान करें।

प्रलेखन इसके खिलाफ चेतावनी नहीं देता है क्योंकि उन चीजों की एक विस्तृत सूची प्रदान करना संभव नहीं है जो आप संभवतः पीआईपी के साथ कर सकते हैं लेकिन जो समर्थित नहीं है। इसके बजाय हम जो समर्थित है उसे दस्तावेज करने के काफी सामान्य दृष्टिकोण पर भरोसा करते हैं और जो कुछ भी दस्तावेज नहीं है उसे असमर्थित माना जाना चाहिए (और यदि आप किसी ऐसी चीज पर भरोसा करना चाहते हैं जो दस्तावेज नहीं है, तो इसे दस्तावेज करने के लिए एक मुद्दा खोलना और इस प्रकार समर्थित )

लंबे समय तक हम एक तिथि आधारित रिलीज योजना की ओर बढ़ने की संभावना रखते हैं (उम्मीद है) कि हम सेवर हैं या नहीं, इस बारे में किसी भी भ्रम को दूर करने के लिए।

मेरे आईफोन से भेजा गया

20 मार्च, 2018 को पूर्वाह्न 11:02 बजे रिच जोन्स नोटिफिकेशन @github.com ने लिखा:

अरे @dstufft , इसमें शामिल होने के लिए धन्यवाद। यह धागा बहुत गर्म हो रहा है!

सबसे पहले, मैं आपके काम के लिए धन्यवाद देता हूं! मुझे पता है कि रखरखाव एक अंतहीन, धन्यवाद रहित कार्य है, और मुझे लगता है कि यह केवल तभी खराब होता है जब आप एक परियोजना को बड़े और लोकप्रिय पाइप के रूप में प्रबंधित करते हैं!

अब, इस मुद्दे पर हाथ में: हालांकि बीस अनुरक्षकों ने अब तक इस समस्या की सूचना दी है, मुझे पता है कि यह पहले से ही हजारों लोगों को प्रभावित कर रहा है - प्रभावित परियोजनाओं में से कुछ अपने आप में बड़े पैमाने पर हैं: एनाकोंडा, ओपनस्टैक, स्पासी, ज़प्पा, और है कई दसियों हज़ारों उपयोगकर्ता। मुझे पता है कि हमारा स्लैक चैनल इस बारे में चर्चाओं से भरा हुआ है। (सचमुच, जैसा कि मैं इसे लिख रहा था, एक नया मुद्दा सामने आया।)

स्पष्ट रूप से, कई महत्वपूर्ण पायथन परियोजनाएं हैं जिन्हें प्रोग्रामेटिक रूप से अपने वातावरण का निरीक्षण करने की क्षमता की आवश्यकता होती है। ऐसा करने में सक्षम होने के लिए यह पूरी तरह से उचित बात है। इसके अलावा, प्रलेखन ने ऐसा करने के खिलाफ कभी चेतावनी नहीं दी - और अभी भी नहीं!

मुझे लगता है कि अब तक की स्थिति है:

संस्करण स्ट्रिंग के प्रारूप को देखते हुए, हम सभी मानते हैं कि पाइप अनुरक्षक सिमेंटिक वर्जनिंग का अनुसरण कर रहे हैं
पाइप अनुरक्षकों ने एक "पैच" जारी किया जिसने व्यापक रूप से तोड़ने वाले परिवर्तन की शुरुआत की
यह परिवर्तन अघोषित और अनिर्दिष्ट था - और मुझे लगता है, अप्रत्याशित और अनपेक्षित
अब, केवल आयात पाइप को कॉल करने से प्रोग्राम तुरंत टूट जाता है, जो अत्यंत डेवलपर-शत्रुतापूर्ण है
यह पायथन पारिस्थितिकी तंत्र में प्रमुख सिरदर्द पैदा कर रहा है
प्रलेखन नहीं करता है (और अभी भी नहीं करता है - इस रेपो के रीडमे में डॉक्स लिंक पर क्लिक करें) पीआईपी प्रोग्रामेटिक रूप से उपयोग करने के खिलाफ चेतावनी देता है।
इस बात की कोई घोषणा नहीं की गई थी कि PATCH अपडेट में आयात पाइप इस नुकसान का कारण बनेगी - यह घोषणा एक ऐसे संस्करण के लिए आई है जो अभी तक जारी नहीं किया गया है।
चेंजलॉग में इस बदलाव का जिक्र तक नहीं किया गया था
हम पाइप या पिप डेवलपर्स को बदलना नहीं चाहते हैं! हम तुमसे प्यार करते हैं!
..लेकिन हम नहीं चाहते कि इस तरह की घटना दोबारा हो!
..इसलिए हम चाहते हैं कि सेवर का पालन किया जाए!
हम वास्तव में, वास्तव में एक और पैच पसंद करेंगे जो इस बड़े ब्रेकिंग परिवर्तन को पूर्ववत करता है!
एक पाइप में एक पर्यावरण का निरीक्षण करने के लिए प्रोग्रामेटिक तरीके की आवश्यकता> = 10.0.0 दुनिया एक और चर्चा का विषय है, लेकिन इस मामले का तथ्य यह है कि हमें कभी नहीं बताया गया था कि हमें पाइप में प्रोग्रामेटिक रूप से पाइप का उपयोग नहीं करना चाहिए। <=9 दुनिया, और एक बड़े पैमाने पर, अघोषित परिवर्तन था, और हम वास्तव में इसे उलटा देखना चाहेंगे क्योंकि यह हजारों लोगों को नकारात्मक रूप से प्रभावित कर रहा है।

एक बार फिर धन्यवाद,
धनी

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

@Miserlou

संस्करण स्ट्रिंग के प्रारूप को देखते हुए, हम सभी मानते हैं कि पाइप अनुरक्षक सिमेंटिक वर्जनिंग का अनुसरण कर रहे हैं

किसी ऐसे व्यक्ति के रूप में जो सेवर का कड़ा विरोध करता है, क्या आप मुझे बता सकते हैं कि इस भ्रम को खत्म करने के लिए मेरे संस्करण के तार किस प्रारूप में होने चाहिए? "तीन बिंदीदार संख्याएं" मेरे लिए "सख्ती से सेवर का पालन करती हैं" का अर्थ नहीं है, इसलिए यह धारणा एक आश्चर्य के रूप में आती है।

इस टिप्पणी के जवाब में: पाइप सेवर का पालन करता है या नहीं, या इसका पालन करने का वादा करता है, major.minor.micro संस्करण योजना का उपयोग अभी भी सूक्ष्म रिलीज के आसपास किसी प्रकार के संयम का एक निहित वादा करता है। यदि ~= 9.0.1 जैसा संगत रिलीज़ पिन उपयोगकर्ताओं को पश्चगामी संगतता में अप्रत्याशित ब्रेक से बचाने के लिए पर्याप्त नहीं है, तो केवल सुरक्षित विकल्प सादा संस्करण मिलान है। यदि संस्करण मिलान के अलावा किसी और चीज का समर्थन करने का कोई इरादा नहीं है, तो पाइप क्रोम-शैली संस्करण योजना पर भी स्विच कर सकता है जिसमें केवल एक मोनोटोनिक रूप से बढ़ने वाला घटक होता है।

संपादित करें: मैं देख रहा हूं कि @dstufft ने पहले से ही दिनांक-आधारित संस्करणों को अपनाकर इस दिशा में आगे बढ़ने का प्रस्ताव रखा है। मुझे लगता है कि इस घटना के परिणामस्वरूप होने वाली संपार्श्विक क्षति का एक दुर्भाग्यपूर्ण टुकड़ा होगा।

तो हाँ, एक स्वयंसेवी संचालित सॉफ़्टवेयर प्रोजेक्ट के उपयोगकर्ताओं के रूप में, हमें उपयोगकर्ता/रखरखाव संबंधों की प्रकृति के लिए प्रशंसा के साथ अपनी अपेक्षाओं को संतुलित करने की आवश्यकता है। यह भी स्पष्ट है कि इस रिलीज़ का उद्देश्य import pip को अचानक विफल करना शुरू करना नहीं था। दूसरी ओर, हालांकि, मुझे लगता है कि लोगों के लिए माइक्रो रिलीज में इस तरह के प्रतिगमन के बारे में निराश होना उचित है, और इस मुद्दे को ठीक करने वाले 9.0.3 संस्करण को जारी करना एक उचित उपाय की तरह लगता है।

एक तरफ के रूप में, मैं इसे निम्न चरणों के साथ वर्चुअलएन्व (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 पायथन का पैकेज मैनेजर है। पायथन एक प्रोग्रामिंग भाषा है। लोगों को अपने परिवेश का प्रोग्रामेटिक रूप से निरीक्षण करने की आवश्यकता है। 1+1=2.

लोगों के लिए यह मानना ​​पूरी तरह से उचित था कि ऐसा करने का यह सही तरीका था। वहाँ नहीं था - और वहाँ _ अभी भी _ नहीं है - दस्तावेज़ीकरण में कुछ भी ऐसा करने के लिए _not_ कह रहा है। एक अनुस्मारक के रूप में, 700,000 से अधिक आवेदन हैं जो इसी निष्कर्ष पर पहुंचे हैं ! इसके अलावा - ऐसा करने का कोई और तरीका नहीं है!

सिर्फ इसलिए कि ReadTheDocs में कुछ प्रलेखित नहीं है, इसका मतलब यह नहीं है कि यह निषिद्ध है - हम सभी हर दिन ऐसी परियोजनाओं का सामना करते हैं और उनका उपयोग करते हैं जो बस इस तरह से कोड प्रदान करते हैं।

यदि कुछ भी हो, तो यह तथ्य कि pip यहां तक ​​कि _has_ एक कमांड लाइन इंटरफ़ेस बिल्कुल भी एक अच्छा संकेत प्रतीत होता है कि इसे एक पुस्तकालय के रूप में इस्तेमाल किया जा सकता है, क्योंकि इसमें पहले से ही एक पायथन क्लाइंट है!

इसके अलावा, हम _ के साथ नामित निजी एपीआई के बारे में बात नहीं कर रहे हैं, जैसा कि सम्मेलन है, या यहां तक ​​​​कि किसी विशिष्ट सार्वजनिक विधि के बारे में, हम केवल _just कॉल आयात_ के बारे में बात कर रहे हैं जो इस विनाशकारी विफलता का कारण बनता है।

वहाँ नहीं था - और अभी भी नहीं है - दस्तावेज़ीकरण में कुछ भी ऐसा नहीं करने के लिए कह रहा है।

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

यदि आप _इस वेरी रेपो_ के "दस्तावेज़" लिंक पर क्लिक करते हैं, तो आप उस पृष्ठ पर नहीं पहुंचेंगे। कोई भी नवीनतम का उल्लेख नहीं कर रहा है। दस्तावेज़ीकरण के आपके अपने लिंक नवीनतम से लिंक नहीं होते हैं। उस पृष्ठ पर जाने का कोई रास्ता नहीं है। सब कुछ स्थिर हो जाता है, जिसमें वह खंड शामिल नहीं है।

@Miserlou मुझे लगता है कि नोट उन लोगों के लिए एक दयालुता है जो किसी भी तरह सोचते हैं कि उन्हें कमांड लाइन टूल के आंतरिक आयात करना चाहिए क्योंकि यह पायथन में लागू होता है और वे आंतरिक आयात योग्य होते हैं।

मुझे लगता है कि आपके पास pip के सार्वजनिक इंटरफ़ेस की मेरे, डेवलपर्स और अधिकांश लोगों की तुलना में एक अलग व्याख्या है जो pip को CLI प्रोग्राम के रूप में सोचते हैं, लेकिन इसका वास्तविक नुकसान क्या है? बस pip != 9.0.2 पिन करें और काम पूरा करें।

यह स्पष्ट है कि हम सभी इस बिंदु पर एक ही पृष्ठ पर हैं कि समर्थित, सार्वजनिक एपीआई का हिस्सा क्या है और क्या नहीं है, और ऐसा कुछ भी नहीं है जो किसी भी तरह से पूर्वव्यापी रूप से सभी को नोटिस पर रखा जा सके।

ईमानदार होने के लिए, पाइप के अनुरक्षकों ने पहले ही कहा है कि यदि समय अनुमति देता है, तो वे इस मुद्दे को ठीक करने का प्रयास करेंगे, हालांकि सभी को चीजों को गति देने के लिए पुल अनुरोध दर्ज करने के लिए प्रोत्साहित किया जाता है।

मुझे लगता है कि अभी के लिए हम केवल यह कर सकते हैं कि तृतीय-पक्ष पुस्तकालयों को इस मुद्दे से अवगत कराया जाए, और उन्हें इस मुद्दे पर इंगित किया जाए। दीर्घकालिक तृतीय-पक्ष पुस्तकालयों को इस मुद्दे को वैसे भी ठीक करने की आवश्यकता है, और उम्मीद है कि वे import pip नहीं करते हैं, लेकिन कमांडलाइन के माध्यम से पाइप को कॉल करें (उपप्रोसेस या इसी तरह के पायथन कमांड के साथ)।

मेरा मानना ​​है कि इस चर्चा के उपयोगी होने की संभावना नहीं है और न ही वास्तव में कुछ और कहा जाना है। यहां है:

• समस्या का पर्याप्त विवरण।
• संभावित कामकाज जो कि कोई इसमें भाग लेने पर नियोजित कर सकता है।
• हम अपने पश्चगामी संगतता दिशानिर्देशों के अनुसार इसे एक महत्वपूर्ण परिवर्तन क्यों नहीं मानते, इसका औचित्य।
• एक बयान कि मैं इसे ठीक करने के लिए समय निकालने का प्रयास करूंगा (हालांकि इसके बारे में कोई वादा नहीं है)।
• एक कॉल टू एक्शन जिसे किया जा सकता है यदि इससे प्रभावित कोई व्यक्ति यह अधिक संभावना बनाना चाहता है कि 9.0.3 फिक्स के साथ मौजूद है।

इस बिंदु पर चर्चा में शामिल सभी लोगों को और निराश करने के अलावा कोई वास्तविक उद्देश्य नहीं है, इसलिए मैं अभी इस मुद्दे से बाहर निकल रहा हूं। यह समस्या या तो 10.0, या 9.0.3 के रिलीज़ होने पर बंद हो जाएगी। यदि कोई कॉल टू एक्शन में प्रयास करता है, तो उनका या तो पुल अनुरोध खोलने या इस मुद्दे पर एक अंतर प्रस्तुत करने के लिए स्वागत है।

इस आयात न करें-पिप मंत्र को और अधिक दृश्यमान बनाने के लिए, नाम स्थान का नाम बदलकर "_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 । मैं इस मुद्दे को संप्रेषित करने के लिए एनाकोंडा टीमों के साथ काम करूंगा और उन्हें पाइप आयात करने से दूर जाने में मदद करूंगा।

इस धागे में रिकॉर्ड के लिए, #5101 ने मेरी समस्या भी हल कर दी।

डिट्टो, #5101 आयात को हमारे टूल के अंदर काम करने की अनुमति देता है। कैविएट एम्प्टर: मैंने न तो पैच किए गए पाइप का परीक्षण किया है और न ही हमारे टूल का बड़े पैमाने पर परीक्षण किया है।

इसे 9.0.3 में तय किया जाना चाहिए।

तेजी से समाधान के लिए धन्यवाद, किसी ऐसे व्यक्ति की ओर से जिसने अपने जीवन में कभी भी import pip नहीं लिखा, लेकिन उस पैकेज का उपभोक्ता था जिसने ऐसा किया। इस धागे को पढ़ने के बाद ऐसा लगता है कि बहुत से ऐप्स ने पाइप आयात किया है, अनजाने में सर्वोत्तम प्रथाओं के खिलाफ, और बहुत से देव और उपयोगकर्ता संभावित रूप से v9.0.2 और v10 से प्रभावित होते हैं।

मैं दूसरी/तीसरी/एनवीं चीजों को आसान बनाने के लिए उचित बहिष्करण चेतावनी जोड़ा जा रहा हूं। शायद एक pypi.python.org पोस्ट भी?

हुर्रे! इसके लिए धन्यवाद!

मुझे वास्तव में एक बहिष्करण चेतावनी भी पसंद है, और, अधिक महत्वपूर्ण बात - एक pip10 दुनिया में प्रोग्रामेटिक रूप से पायथन वातावरण का निरीक्षण करने के तरीके पर उचित निर्देश! स्पष्ट रूप से इसकी आवश्यकता है, यह देखते हुए कि इस बग से 700,000 से अधिक आवेदन प्रभावित हुए थे।

pip list --format=json ?

सबसे पहले आप लोगों को पिप करने में योगदान देने के लिए धन्यवाद, इसके लिए मेरे सभी उपयोग के मामलों को कुछ उपयोगकर्ता के अनुकूल विकल्पों और तर्कों के साथ पूरी तरह से कवर किया गया है।

इस "आश्चर्यजनक रूप से व्यापक रूप से अपनाया गया और उपयोगी अपरिभाषित व्यवहार" के कारण, क्या हमें git के लिए एक piplib को libgit2 के रूप में बनाने की आवश्यकता है? कृपया ध्यान दें कि libgit2 git के साथ कोई कोड साझा नहीं कर रहा है, और git के अन्य समूह द्वारा बनाए रखा जाता है। और यह git इकोसिस्टम के लिए अच्छा है। हो सकता है कि पिपलिब कुछ दिलचस्प उपयोग के मामलों को कवर करेगा जिनकी हमें उम्मीद नहीं थी।

यहाँ एक ऐसी ही कहानी है: https://public-inbox.org/git/1267957655.3759.29.camel@mattotaupa/T/

@drunkwcodes मुझे संदेह है कि आप जो प्रस्तावित करते हैं वह पहले से ही मौजूदा पैकेजों में लागू किया गया है, जिसमें पाइप प्रलेखन का उल्लेख है , packaging , setuptools , और distlib । जहां तक ​​​​मैं इस धागे से बता सकता हूं, कार्यक्षमता में अंतर के साथ कोई समस्या नहीं है, लेकिन कुछ लोगों को ऐसे उपकरणों की समस्या है जो हर मॉड्यूल को आयात और निरीक्षण करने का प्रयास करते हैं, और आयात विफलताओं को घातक त्रुटियों के रूप में मानते हैं।

मुझे ऐसा लगता है कि इस तरह के उपकरण एक कोशिश/छोड़कर ब्लॉक में आयात विवरण लपेटकर इस समस्या के आसपास काम कर सकते हैं, लेकिन यह भी सेट करने के लिए एक संदिग्ध उदाहरण की तरह लगता है। पीआईपी 9.0.3 की रिलीज को देखते हुए, हालांकि, मुझे लगता है कि यह शायद आयात के मुद्दे पर बहस करने के लिए समय के लायक नहीं है जब तक कि समस्या फिर से पीआईपी 10 में नहीं होती है। वैसे भी, जब तक रखरखाव करने वाले अपने रास्ते से बाहर नहीं जाते हैं import pip विफल हो जाते हैं, या ऐसी विफलताओं को ठीक करने वाले पैच को संक्षेप में अस्वीकार कर देते हैं, तो खड़े होने के लिए सामान्य आधार होगा।

@sruggier सभी पैकेज अच्छे हैं, और WheelFile.install() को भी और प्रचार की आवश्यकता है। लेकिन एक-स्टॉप सेवा pip.main() प्रदान की गई उपरोक्त सभी के साथ अपरिवर्तनीय है। यह अभी भी कोशिश करने लायक है।

सबसे महत्वपूर्ण यह है कि मुझे उम्मीद है कि इन जरूरतों को किसी अन्य परियोजना द्वारा पूरा किया जाएगा, और pip10 बिना किसी अतिरिक्त गारंटी के आसानी से पहुंच जाएगा। बहिष्करण और कोड आधार को छोटा करना एक प्रमुख रिलीज के लिए संपूर्ण बिंदु हैं।

स्थायी बुनियादी ढांचे "सॉफ्टवेयर" के लिए ठोस कार्यान्वयन विवरण हास्यास्पद है। आप प्रलेखित दुर्व्यवहार के मामले में अनुरक्षकों का न्याय नहीं कर सकते हैं और पिप का पहिया वापस पकड़ सकते हैं।

यदि आप पीआईपी को एक lib के रूप में उपयोग करने का आग्रह करते हैं, तो कई धारणाओं पर पुनर्विचार करने की आवश्यकता होगी।

@drunkwcodes स्पष्ट होने के लिए, pip.main() प्रतिस्थापित करने का सबसे आसान उपयोग है - आपको बस subprocess.run([sys.executable, '-m', 'pip', <rest of args>]) का उपयोग करने की आवश्यकता है।

साथ ही, WheelFile.install() को बढ़ावा नहीं देने का कारण यह है कि व्हील प्रोजेक्ट ने यह भी कहा है कि वे उपयोगकर्ता-दृश्यमान API प्रदान नहीं करते हैं - हमने मूल रूप से पाइप डॉक्स में व्हील का उल्लेख किया है, लेकिन उनके अनुरोध पर इसे हटा दिया है। पहिया पीईपी इस बारे में बहुत स्पष्ट है कि आप पहिया कैसे स्थापित करते हैं, हालांकि - तीसरे पक्ष के मॉड्यूल में इसे लागू करना मुश्किल नहीं है।

मैं पाइप पर आप सभी के काम की सराहना करता हूं, और जानता हूं कि यह आसान नहीं है। लेकिन रिकॉर्ड के लिए:

मैं थोड़ा निराश हूं कि लोग पहले से ही आयात पाइप से दूर नहीं हुए हैं। इस मुद्दे से प्रभावित लोगों को अभी भी पिप 10 के लिए तैयारी करने की आवश्यकता होगी

स्पासी import pip से दूर चला गया है । लेकिन कुछ लोग अभी भी स्पासी 1 का उपयोग कर रहे हैं, जिसने पाइप आयात किया --- और स्पष्ट कारणों से, पैच रिलीज के लिए पाइप को पिन नहीं किया। यदि परिवर्तन v10 में होता, तो हमारे पुराने संस्करण प्रभावित नहीं होते। हमने इसे संबोधित करने के लिए अभी एक हॉटफिक्स जारी किया है।

एक pip10 दुनिया में प्रोग्रामेटिक रूप से पायथन वातावरण का निरीक्षण करने के तरीके पर उचित निर्देश

डिस्लिब पर पीपीए की स्थिति क्या है? पिप स्पष्ट रूप से इसे कुछ क्षमता में उपयोग कर रहा है, लेकिन यह भी पैकेजिंग का उपयोग कर रहा है, जो डिस्लिब को बहिष्कृत करने का इरादा रखता है।

यदि कोई आधिकारिक पद नहीं है, तो कम से कम वर्तमान विचारों और पिप के मुख्य अनुरक्षकों की राय की बहुत सराहना की जाएगी। यदि इस विषय पर कहीं और प्रासंगिक चर्चाएं हैं, तो अन्य चर्चाओं के लिए एक साधारण सूचक मेरे लिए काफी अच्छा है।

मुझे पता नहीं है कि डिस्लिब पैकेजिंग को बहिष्कृत करता है। इसमें "distutils2/packaging" का उल्लेख है लेकिन distutils2 कुछ अलग था।

मेरा व्यक्तिगत विचार यह है कि डिस्टलिब और पैकेजिंग दोनों ही उपयोग करने के लिए पूरी तरह से उचित चीजें हैं। आपको यह पुष्टि करने के लिए स्वयं उनका मूल्यांकन करना चाहिए कि वे आपकी आवश्यकताओं को पूरा करते हैं, जाहिर है, किसी भी अन्य निर्भरता की तरह जिस पर आप भरोसा करते हैं।

हो सकता है कि पदावनत शब्द का बहुत मजबूत हो। मेरी वर्तमान समझ का स्रोत:

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

आह, यह एक अलग "पैकेजिंग" है - यह प्रस्तावित stdlib मॉड्यूल था जिसका उद्देश्य distutils को प्रतिस्थापित करना था। यह PyPI packaging प्रोजेक्ट से बिल्कुल अलग है। डिस्लिब प्रोजेक्ट से उस भेद को थोड़ा बेहतर स्पष्ट करने के लिए कहना उचित हो सकता है।

डिस्लिब प्रोजेक्ट से उस भेद को थोड़ा बेहतर स्पष्ट करने के लिए कहना उचित हो सकता है।

पहले ही किया है :) देखें: https://bitbucket.org/pypa/distlib/issues/100/clarify-project-positioning-and-status

इस थ्रेड को स्वचालित रूप से लॉक कर दिया गया है क्योंकि इसे बंद करने के बाद हाल ही में कोई गतिविधि नहीं हुई है। कृपया संबंधित बग के लिए एक नया मुद्दा खोलें।