Pip: pip, pipX, और pipX.Y को हटा दें

मुझे पाइप से _pip की ओर जाना पसंद है,
इस तरह पाइप का कार्यान्वयन अधिक "निजी" नामस्थान पर जाता है
खर्च उपकरण तोड़ रहा है जो पिप्स इंटर्नल में जाता है

दूसरा खर्च यह है कि अगर हम कभी भी एक सार्वजनिक एपीआई बनाना चाहते हैं तो हम या तो एक ही नामस्थान (जो भी pip.py में है) तक सीमित हैं या हमें इसे वापस पैकेज में बदलने की जरूरत है (और संभवतः पायथन को तोड़ना होगा) 2.6 फिर से, जब तक कि हम इसे तब तक हटा नहीं देते)।

बेशक, हम कभी भी सार्वजनिक एपीआई नहीं बना सकते हैं, इस मामले में, मुद्दा विवादास्पद है।

मैं मदद नहीं कर सकता लेकिन सोचता हूं कि @warsaw और @ncoghlan शायद इस पर भी कुछ राय रखते हैं।

शायद @bkabrda भी! और @tdsmith

उस पहले बिंदु की शक्ति को कम मत समझो। इंटरटिया _high_ है: बहुत सारे टूल pip मान लेंगे, और _lots_ दस्तावेज़ीकरण गलत होगा। एक लंबा बहिष्करण चक्र होना मूल रूप से यहां अनिवार्य है। अन्यथा, मुझे लगता है कि यह एक अच्छा विचार है: +1।

-1 पाइप हटाने पर मुझे अपनी सभी परिनियोजन स्क्रिप्ट बदलनी होगी।
pipX और pipX.Y . को हटाने पर +1

मंगलवार, 6 अक्टूबर, 2015 को सुबह 08:16 बजे, कोरी बेनफ़ील्ड ने लिखा:

उस पहले बिंदु की शक्ति को कम मत समझो। इंटरटिया है
_high_: बहुत सारे उपकरण पाइप मानेंगे, और _lots_ दस्तावेज़ीकरण
गलत होगा। एक लंबा बहिष्करण चक्र होना मूल रूप से अनिवार्य है
यहां। अन्यथा, मुझे लगता है कि यह एक अच्छा विचार है: +1।

— इस ईमेल का सीधे उत्तर दें या इसे GitHub[1] पर देखें।

कड़ियाँ:

1. https://github.com/pypa/pip/issues/3164#issuecomment -145839321

उस पहले बिंदु की शक्ति को कम मत समझो। इंटरटिया _high_ है: बहुत सारे टूल pip मान लेंगे, और _lots_ दस्तावेज़ीकरण गलत होगा। एक लंबा बहिष्करण चक्र होना मूल रूप से यहां अनिवार्य है।

जी, पूर्णतया सहमत। मैं अनिवार्य रूप से मानता हूं कि हमारे पास परिभाषित हटाने की तारीख नहीं होनी चाहिए (और संभवतः कभी नहीं) और बस इसे stderr को एक संदेश लॉग करना चाहिए।

मैं अनिवार्य रूप से मानता हूं कि हमारे पास परिभाषित हटाने की तारीख नहीं होनी चाहिए (और संभवतः कभी नहीं) और बस इसे stderr को एक संदेश लॉग करना चाहिए।

मुझे नहीं लगता कि यह काम करेगा। बिना किसी परिभाषित "आपकी गंदगी एक्स से बाद में टूट जाएगी" तारीख के साथ कष्टप्रद चेतावनियों को प्रिंट करना वास्तव में मदद नहीं करता है: लोग केवल चेतावनियों को अनदेखा करेंगे। मुझे लगता है कि अगर आप ऐसा करना चाहते हैं तो आपको एक तारीख तय करनी चाहिए (संभवतः एक _far_ दूर, लेकिन फिर भी)। चर्चा शुरू करने की एक संभावित तारीख: जब पायथन 2.6 के साथ अंतिम आरएचईएल एलटीएस रिलीज का समर्थन बंद हो जाता है (यह अभी भी बहुत दूर है, लेकिन चर्चा के लायक है)।

-1 पाइप हटाने पर मुझे अपनी सभी परिनियोजन स्क्रिप्ट बदलनी होगी।
pipX और pipX.Y . को हटाने पर +1

मुझे नहीं लगता कि pipX और pipX.Y को बिना pip के लिए किए बिना पदावनत करना (जल्द ही किसी भी समय हटाने के बारे में बात नहीं करना) समझ में आता है क्योंकि यह यकीनन बदतर अपराधी है उन सब का।

चर्चा शुरू करने की एक संभावित तारीख: जब पायथन 2.6 के साथ अंतिम आरएचईएल एलटीएस रिलीज का समर्थन बंद हो जाता है (यह अभी भी बहुत दूर है, लेकिन चर्चा के लायक है)।

यह अच्छा विचार है।

चर्चा शुरू करने की एक संभावित तारीख: जब पायथन 2.6 के साथ अंतिम आरएचईएल एलटीएस रिलीज का समर्थन बंद हो जाता है (यह अभी भी बहुत दूर है, लेकिन चर्चा के लायक है)।

आरएचईएल 6 प्रोडक्शन 3 फेज की समाप्ति के लिए यह 30 नवंबर, 2020 है। उनके पास इससे परे एक सुपर स्पेशल विस्तारित जीवन चक्र है, लेकिन शायद हम सिर्फ 2020 को लक्षित कर सकते हैं और अगर हम 2020 तक रोल करते हैं और पायथन 2.6 अभी भी व्यापक समर्थन में है, तो हम इसे और पीछे धकेलते हैं।

एक अन्य विकल्प यह होगा कि पाइप को उसी पायथन वातावरण में निष्पादित करने की आवश्यकता को रोकना होगा जिसमें वह चीजों को स्थापित कर रहा है ...

ईमानदार होने के लिए, मुझे यकीन नहीं है कि कैसे pip install -p python2.7 python2.7 -m pip install से बेहतर है। हमें उस पायथन का निरीक्षण करना होगा जिसे हम उससे जानकारी प्राप्त करने के लिए स्थापित कर रहे हैं, इसलिए या तो हम डेटा को आगे और पीछे घुमाने के लिए उस पायथन में सबहेल करने जा रहे हैं (जैसे मेरा आधा किया गया वर्चुअलएन्व रीराइट करता है) या हमें जारी रखने की आवश्यकता होगी एक ही पायथन पर्यावरण द्वारा निष्पादित किया जाना है। ऐसा लगता है कि डेक कुर्सियों को किसी और चीज से ज्यादा घुमाया जा रहा है।

उस विशेष विचार के लिए मुख्य लाभ यह होगा कि आपको केवल एक बार पाइप को अपग्रेड करना होगा।

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

यह इस तथ्य को संबोधित नहीं करता है कि विंडोज़ पर pip install --upgrade pip चल रहा है क्योंकि ओएस के पास pip.exe के लिए एक हैंडल खुला है, जो मुझे नहीं लगता कि python -m का उपयोग किए बिना हल किया जा सकता है @pfmoore को सही ढंग से समझता हूं।

मुझे लगता है कि @sYnfo मुझसे ज्यादा इस पर टिप्पणी करना चाहता है, क्योंकि मैं अब फेडोरा/आरएचईएल में पायथन का रखरखाव नहीं करता।

आह, यह सही है, मैं भूल गया। माफ़ करना!

(लेकिन मैं व्यक्तिगत रूप से सोचता हूं कि भले ही इन्हें हटा दिया गया हो, फिर भी हम उन्हें वितरण स्तर पर उस रूप में प्रदान करेंगे जो हमारे द्वारा शिप किए जाने वाले पायथन दुभाषियों के सेट के लिए सबसे अच्छा है; कम से कम यह मेरा पहला विचार था जब मैंने प्रस्ताव पढ़ा.. . हमारे पास Python एक्जिक्यूटिव के लिए एक सामान्य नीति है जो फेडोरा में इसे अनिवार्य करती है।)

• बहिष्करण के लिए +1 - लेकिन मुझे दस्तावेज़ीकरण में बहिष्कृत करने के लिए पर्याप्त खुशी होगी, स्क्रिप्ट को स्वयं उपयोगकर्ता पर विलाप न करें।
• विंडोज़ पर यह केवल 6 और अक्षर हैं - py -m pip :-)
• 2.6 के लिए, मैं या तो लोगों को pip का उपयोग जारी रखने देता हूं या python2.6 -m pip.__main__ की सलाह देता हूं। मुझे नहीं लगता कि उन्हें कोई अन्य समाधान देने के लिए पाइप में बदलाव करना उचित है।

जड़ता का मुद्दा बहुत बड़ा है, और मुझे नहीं लगता कि हमें इससे सीधे लड़ना चाहिए। इसके बजाय, हमें "पायथन-एम पीआईपी" फॉर्म का उपयोग करने के लिए प्रलेखन को स्विच करना चाहिए, और उस फॉर्म को आधिकारिक पीपीए नीति बनाना चाहिए (जिसके द्वारा मेरा मतलब है कि हम जो कुछ भी पोस्ट करते हैं, उसमें लगातार उस फॉर्म का उपयोग करने के लिए दर्द होता है)। हो सकता है कि प्रसिद्ध परियोजनाओं को नए रूप में बदलने के लिए उन्हें स्थापित करने के लिए पीआर की पेशकश करें। एक बार python -m pip फॉर्म के सामान्य उपयोग में थोड़ा सा कर्षण प्राप्त करने के बाद हम स्क्रिप्ट को औपचारिक रूप से बहिष्कृत करने और/या हटाने के बारे में चिंता कर सकते हैं।

मुझे लगता है कि मेरी सफलता का मानदंड इसे वह मंत्र बना रहा है जो लोगों को स्टैक ओवरफ्लो से मिलता है। चाँद के लिए गोली मारो, आदि।

मुझे लगता है कि एक तर्क के साथ एक लिंक करने योग्य इरादा-से-बहिष्कृत संदेश प्रकाशित करने से तीसरे पक्ष के रखरखावकर्ताओं को दस्तावेज़ीकरण पीआर स्वीकार करने में मदद मिल सकती है।

यहां संदेश भेजना मुश्किल है, क्योंकि pip को पदावनत करने का अर्थ _pip_... को पदावनत करना नहीं है।

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

मैं पदावनति के लिए +1 हूं—ऐसा लगता है कि यह अपस्ट्रीम के दृष्टिकोण से पूरी तरह से समझ में आता है और मुझे ऐसा कोई मुद्दा नहीं दिखता है जो डाउनस्ट्रीम का कारण बन सकता है।

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

( @bkabrda अगर मैं दिशानिर्देशों को सही ढंग से समझता हूं, तो वे केवल सभी MAJOR.MINOR निष्पादन योग्य _iff_ शिपिंग को अनिवार्य करते हैं, पहली जगह में कोई निष्पादन योग्य हैं, यह समस्या पूरी तरह से पाइप निष्पादन योग्य को हटाने के बारे में है, है ना?)

इसके अलावा +1 को या तो पाइप रखने के लिए या अजगर -एम पाइप का उपयोग करने के लिए। __ मुख्य __ अजगर 2.6 के साथ।

कुछ बिंदु जो सामने नहीं आए:

• क्या यह समस्या को केवल python पर नहीं ले जाता है? python (विभिन्न संस्करणों और विभिन्न वर्चुअलएन्व्स में) का ट्रैक रखना pip से अधिक आसान क्यों है?
• यदि आप वर्चुअलएन्व का उपयोग कर रहे हैं (जो अधिकांश लोगों को होना चाहिए), pip स्पष्ट रूप से सक्रिय को संदर्भित करता है। एक वैकल्पिक समाधान यह होगा कि लोगों को हमेशा वेनव का उपयोग करने के लिए प्रोत्साहित किया जाए, जो अन्य समस्याओं को भी हल करता है, उदाहरण के लिए निर्भरता एक वैश्विक वातावरण में सब कुछ छोड़ने से संघर्ष करती है।

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

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

भी,

pip3.4 पर्याप्त विशिष्ट नहीं है, आपके पास 3.4.0 और 3.4.1 स्थापित हो सकते हैं।

क्या यह वास्तव में अक्सर सामने आता है? मैं उत्सुक हूं कि आप उनके बीच अंतर कैसे कर रहे हैं, क्योंकि मुझे नहीं लगता था कि पाइथन सामान्य रूप से खुद को pythonX.Y नाम से अधिक विशिष्ट स्थापित करेगा (और जब तक कि उनके पास अलग-अलग उपसर्ग न हों, ऐसा लगता है कि यह भी कोशिश करेगा वैसे भी साइट-पैकेज साझा करें)।

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

मैं यहां थोड़ा डिस्कनेक्ट हो सकता हूं, लेकिन pip को एक ऐसे उपनाम से क्यों न बदलें जो प्रभावी रूप से कुछ ऐसा था:

alias pip=/usr/bin/env python -m pip

या एक स्क्रिप्ट जो इसके समान थी /usr/local/bin/pip में स्थापित करने के लिए।

इस तरह हम pip नहीं खोते हैं, और यह सार्वभौमिक रूप से हर जगह काम करता है।

यह भी सुनिश्चित नहीं है कि आप जिन समस्याओं का सामना कर रहे हैं, उन्हें हल करता है, बस मेरा $0.02। : क्रोध3:

@erikrose
यह समस्या को python में स्थानांतरित कर देता है, लेकिन आम तौर पर मैंने जो भ्रम देखा है वह python और pip असहमत होने पर उत्पन्न होता है। जैसे कि आपके पास /usr/bin/python और /usr/local/bin/python हो सकता है और यदि python अंक /usr/local/bin/python और pip अंक /usr/bin/python के लिए यह एक है भ्रम के लिए नुस्खा। इसलिए हम दोनों के असहमत होने से उत्पन्न भ्रम को पूरी तरह से समाप्त कर देते हैं, लेकिन इसके असहमत होने की किसी भी क्षमता को हटा देते हैं। आप अभी भी इस बात को लेकर असमंजस में हैं कि python का क्या अर्थ है, लेकिन मुझे नहीं लगता कि इसके बारे में कुछ भी किया जा सकता है, और विशेष रूप से हमारे द्वारा नहीं।

एक आभासी वातावरण इस मुद्दे को _harder_ हिट करने के लिए बनाता है, लेकिन मुझे लगता है कि यह अभी भी संभव है। मेरा पेट मुझे बताता है कि नए उपयोगकर्ता (जिनके द्वारा इसके द्वारा फंसने की सबसे अधिक संभावना है) शायद धार्मिक रूप से आभासी वातावरण का उपयोग नहीं करने वाले हैं (यदि वे उनका उपयोग कर रहे हैं)।

@rschoon
हम संभवतः ऐसा कर सकते हैं, इसे पाइप के अंदर एक स्थायी विशेष मामले की आवश्यकता होगी जब पाइप स्वयं स्थापित हो (क्योंकि वर्चुअल वातावरण में कोई setup.py नहीं है) लेकिन यह निश्चित रूप से एक संभावना है। इसके साथ मेरा मुख्य डर यह है कि ऐसा लगता है कि किसी भी तरह से python -m pip का उपयोग करना हमेशा बेहतर होगा क्योंकि यह वर्चुअल वातावरण के अंदर और बाहर काम करता है, बजाय इसके कि आप इसमें हैं या नहीं, इसके आधार पर कमांड स्विच करना याद रखें। एक या नहीं।

मुझे यकीन नहीं है कि 3.4.0 और 3.4.3 कितनी बार बात आती है। मुझे पता है कि यह OSX पर सुपर असामान्य नहीं है क्योंकि आपके पास /usr/bin/python में सिस्टम प्रदान किया गया Python है और आप Python.org इंस्टॉलर या Homebrew या Macports या pyenv (या उपरोक्त का कुछ संयोजन) भी स्थापित कर सकते हैं।

@mattrobenolt

मूल रूप से, क्योंकि यह बहुत भ्रमित करने वाला है यदि आप पहले आभासी वातावरण को सक्रिय किए बिना myvenv/bin/pip चलाने जैसा कुछ कर रहे हैं या यदि आपके पास एक गैर मानक स्थान पर स्थापित पायथन की एक प्रति है /opt/my-app और आप /opt/my-app/bin/pip चलाते हैं /opt/my-app/bin/python को प्रबंधित करने की अपेक्षा करें।

जब वे इस समस्या से पीड़ित नहीं होते हैं, तो यह आभासी वातावरण के लिए एक बुनियादी pip स्क्रिप्ट को खोने जैसा लगता है।

असली अजगर के रूप में मुझे लगता है कि मुझे अधिक सटीक pip-<python binary path> प्रकार की कंसोल स्क्रिप्ट देखने में कोई आपत्ति नहीं होगी, और डिस्ट्रो पैकेजर्स को सिस्टम-प्रबंधित पिप्स के लिए सरल स्क्रिप्ट पर काम करने दें।

-1 दूसरों पर pip , +1 को बहिष्कृत करने पर।
मैं अपने कुछ फ़्रेमिंग विचारों पर विस्तार करना चाहता हूं, जो इस बात पर चर्चा करने में मदद कर सकते हैं कि इतना बड़ा मुद्दा क्या है। यदि आप केवल समाधान पर मेरे विचार पढ़ना चाहते हैं तो विराम पर जाएँ।

एक शुरुआत के लिए, आप देखना चाहते हैं कि हमें यह समस्या क्यों है, और क्या यह किसी और के समान है? यह एक चल रहे सिस्टम पर कई अजगर होने और अनुमति देने से आता है। इसलिए सिस्टम पैकेज मैनेजरों के पास यह समस्या नहीं है, क्योंकि उदाहरण के लिए, आप डेबियन जेसी और डेबियन व्हीजी को एक ही समय में एक सिस्टम पर नहीं चला सकते (नहीं कर सकते); इसलिए इसे उदाहरण के लिए libreoffice3.5 और libreoffice4.3 को प्रबंधित करने की आवश्यकता नहीं है। हालाँकि कई अन्य भाषा पैकेज प्रबंधकों को उसी समस्या से निपटना शुरू हो जाता है, जब उनके पास भी कई संस्करण स्थापित होते हैं। जैसा कि @erikrose का उल्लेख है, यहां तक ​​​​कि अजगर भी पहले से ही इस मुद्दे पर निर्णय लेता है कि python अब एक से अधिक स्थापित होने पर क्या है।

मैं बहुसंख्यक पायथन उपयोगकर्ताओं के पीओवी से भी इस मुद्दे को देखना चाहता हूं। ध्यान दें कि यह 2 से अधिक अजगर स्थापित लोगों के लिए एक वास्तविक दर्द बिंदु बन गया है (या अधिक-तो)। अन्यथा pip काम करेगा, या बस pip2 और pip3 (और शायद सभी के लिए चर्चा शुरू करने के लिए पर्याप्त जड़ता नहीं होगी)। इसके अलावा यह वास्तव में जटिल होने लगता है। लेकिन मेरा मानना ​​​​है कि ज्यादातर अजगर उपयोगकर्ता सिर्फ एक अजगर का उपयोग करके खुश हैं। यहां तक ​​​​कि अगर उनका सिस्टम उन्हें किसी बिंदु पर 2 देता है, या वे अपग्रेड करने के बजाय / (पिछले को हटाने और एक नया स्थापित करने) के बजाय कई स्थापित करने का प्रबंधन करते हैं - अगर उन्हें चीजें सही लगीं, तो वे केवल एक अजगर के साथ ठीक होंगे, और विस्तार से, उस अजगर का pip । इन सभी उपयोगकर्ताओं के लिए अचानक pip लेना कोई मतलब नहीं है और यह केवल दर्दनाक है।

दर्द का दूसरा बड़ा स्रोत तब होता है जब कोई पिछले मौजूदा एक पर एक नया पायथन स्थापित करने की कोशिश करता है, लेकिन पूरे पर्यावरण के लिए कहानी नए (या "पुराने को लेना") में माइग्रेट की जा रही है। उस स्थिति में मैं यह भेद करना चाहता हूं कि यह स्थापित कहानी की गलती है, न कि कई अजगरों का अस्तित्व। उदाहरण के लिए कोई "नया अजगर स्थापित करने" की उम्मीद कर रहा है! लेकिन इसे अपने रास्ते पर नहीं ला रहे हैं। यहां तक ​​​​कि पुराने अजगर को अनइंस्टॉल करने से, उन्हें वह वातावरण देने के बारे में कुछ नहीं किया जा सकता है जो वे चाहते हैं (उनके रास्ते पर नया अजगर)।

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

अब इस बात को ध्यान में रखते हुए, मुझे ये समाधान पसंद हैं:

• स्पष्ट रूप से pip<versionstuff> समाधान के रूप में बिल्कुल भी अच्छा नहीं है। इसलिए मैं इसे हटाने के लिए सहमत हूं। अधिकांश समय एक अच्छे समाधान की प्रतीक्षा करना बेहतर होता है (यदि यह मौजूद है) कोशिश करने और एक के साथ चलते रहने के लिए जो कई मुद्दों को हल करता है।
• pip (या अन्य pip2 s या pip3 s, यहां तक ​​कि) को बिना पूछे बदलना बंद कर दें। यहां तक ​​कि सिस्टम पैकेज मैनेजर भी ऐसा करते हैं। वे पहले से पूछते हैं। तो हमें चाहिए। इस तरह, कम से कम, उपयोगकर्ता तुरंत देखता है कि कोई समस्या है और शायद वह अपने लिए निर्णय ले सकता है कि वे pip क्या बनना चाहते हैं। इसके साथ कोई बहुत कुछ कर सकता है - देखें कि मौजूदा pip किसका पायथन इंस्टॉलेशन है - यह वही है जो वर्तमान pip खुद को स्थापित करने की कोशिश कर रहा है, तो यह ठीक हो सकता है। अन्यथा उपयोगकर्ता को --yes या --replace कहें या एक संकेत के लिए Y का उत्तर दें। ध्यान दें कि यह अन्य यूजरलैंड-प्रोग्राम-दैट-आओ-फ्रॉम-पीपीआई के साथ एक ही समस्या के साथ मदद कर सकता है। सुनिश्चित करें कि उपयोगकर्ता निष्पादन योग्य स्क्रिप्ट को बदलना चाहता है। भले ही इसका मतलब है कि हमें लोगों को यह बताने के लिए लंबा इंतजार करना होगा कि उन्हें डिफ़ॉल्ट रूप से pip install पर कॉल करने के बाद बातचीत करनी पड़ सकती है (पाइप के स्क्रिप्टेड उपयोग के लिए), और उन्हें --replace-scripts जोड़ने के लिए समय दें। (या w/e) उनके कॉलआउट के लिए, ऐसा ही हो।
• इंस्टॉल में चीजें कहां से आती हैं, इसके बारे में कुछ जानकारी आउटपुट करना शुरू करें! इससे कई समस्याओं का तत्काल समाधान हो सकता है। अगर मैं पाइप के साथ एक पैकेज स्थापित करता हूं, तो पाइप बात नहीं करता
  
  
  
  • यह किस अजगर पर/से है?
  
  
  • यह कौन सा संस्करण है, जहां इसे स्थापित किया गया है
  
  
  • जहां यह नया पैकेज स्थापित कर रहा है
  
  

यह सब जानने के लिए सुपर उपयोगी जानकारी होगी। यह तुरंत मुझे दिखाएगा कि pip मैं कमांड लाइन पर कॉल कर रहा हूं, वह वास्तविक पाइप नहीं है जो मैं चाहता हूं, जो कि बहुत से उपयोगकर्ताओं को चकमा देता है। यह मुझे यह भी दिखाएगा कि मैं सही अजगर के लिए और सही site-packages में स्थापित कर रहा हूं।

मेरा विशेष रूप से मानना ​​है कि उपरोक्त अंतिम दो बिंदुओं को लागू करने से इस मुद्दे के संबंध में बहुत सी औसत उपयोगकर्ता-समस्याएं दूर हो जाएंगी। कई मामलों में उन्हें समस्या जानने और स्वयं समाधान करने का अधिकार होगा।

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

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

6 अक्टूबर, 2015 को दोपहर 1:16 बजे, मार्कस स्मिथ ने नोटिफिकेशन @github.com लिखा:

जब वे इस समस्या से पीड़ित नहीं होते हैं, तो ऐसा लगता है कि वर्चुअल वातावरण के लिए एक मूल पाइप स्क्रिप्ट खोना एक नुकसान है।

असली अजगरों के लिए मुझे लगता है कि मुझे एक और सटीक पाइप देखने में कोई दिक्कत नहीं होगी-कंसोल स्क्रिप्ट टाइप करें, और डिस्ट्रो पैकेजर्स को सिस्टम-प्रबंधित पिप्स के लिए सरल स्क्रिप्ट पर काम करने दें।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

यह दोनों लोगों के लिए पुराने व्यवहार को वापस पाने के लिए तुच्छ बना देगा (बस पाइप-क्ली स्थापित करें) और स्क्रिप्ट को आभासी वातावरण के अंदर रखना आसान बनाता है (बस उन्हें पाइप-क्ली भी स्थापित करें)।

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

tl;dr क्या आप स्थानीय संस्थापन के लिए अपने प्रोजेक्ट में $ npm install grunt हैं, फिर $ npm install -g grunt-cli अपने आप को एक वैश्विक $ grunt देने के लिए, जो केवल स्थानीय इंस्टाल पैकेज का उपयोग करके समाप्त होता है .

मेरी समझ से, यह वही लगता है जो आप प्रस्तावित कर रहे हैं?

@mattrobenolt एक मायने में यह मददगार नहीं है, क्योंकि यह अभी भी आपके सिस्टम पर नोडज के एक संस्करण/एक संस्करण के बारे में बात कर रहा है। यदि आपके पास दो नोड इंस्टॉल हैं, तो वैश्विक grunt स्क्रिप्ट किससे संबंधित है?

नोड का इस अर्थ में "लाभ" भी है कि इसके पैकेज इंस्टॉलेशन डिफ़ॉल्ट रूप से स्थान-स्थानीय हैं, जो कि अजगर के विपरीत है। वर्चुअलएन्व में भी, आप "विश्व स्तर पर" पैकेज स्थापित कर रहे हैं, लेकिन एक अलग वातावरण में (आपके सिस्टम के बजाय)।

यदि आपके पास दो नोड इंस्टॉल हैं, तो वैश्विक ग्रंट स्क्रिप्ट किससे संबंधित है?

यह तकनीकी रूप से मायने नहीं रखता, क्योंकि यह वास्तविक pip में सिर्फ एक शिम है जो आपके वर्चुअलएन्व में स्थापित है या जो कुछ भी आप कर रहे हैं।

हमारे मामले में, यह सिस्टम में स्थापित हो सकता है python , जो कुछ भी अजगर है, यह एक कार्यान्वयन विवरण है। इसे सिर्फ खोल देने की जरूरत है।

क्योंकि वह अभी भी आपके सिस्टम पर नोडज के केवल एक इंस्टॉल/एक संस्करण के बारे में बात कर रहा है

आप मान रहे हैं कि लोग nvm या किसी अन्य virtualenv जैसे टूल का उपयोग नहीं करते हैं? वही विचार।

लेकिन फिर, मेरा संदर्भ ज्यादातर एक उपयोगकर्ता होने तक ही सीमित है, इसलिए मुझे यकीन है कि ऐसे कई संदर्भ हैं जिन पर मैं ध्यान नहीं दे रहा हूं। समाधान होने का दावा नहीं करना, बस जंगली में अन्य चीजों के उदाहरणों का हवाला देना जो समान चीजें करते हैं।

भले ही grunt-cli कोड काफी स्थिर है, यह वास्तव में "इससे कोई फर्क नहीं पड़ता" जो इसे वहां रखता है, विवाद का मुद्दा यह है कि यह किस प्रकार की गड़बड़ी है। जैसा कि मैंने नोड-लैंड में 99% बार कहा था कि यह एक पथ-स्थानीय ग्रन्ट होगा, और आपके लिए सब कुछ तय हो गया है। आप पहले से ही जानते हैं कि आपके वर्तमान पथ पर आपका प्रोजेक्ट किस नोडज का उपयोग कर रहा है। हालाँकि दुर्भाग्य से यह अजगर के मामले में नहीं है।

अगर मेरे पास अजगर 2 और अजगर 3 स्थापित है, और मैं pip पर कॉल करता हूं, भले ही यह pip एक pip-cli ( install -g crunt-cli के बराबर) द्वारा प्रदान किया गया था। दो अजगरों में से एक, किस अजगर के पाइप को वैश्विक pip स्क्रिप्ट कॉल करना चाहिए? यहां अब हमारा मार्गदर्शन करने के लिए पथ-स्थानीय प्रणाली नहीं है।

इवोज के लिए +1, लेकिन विशेष रूप से:

इंस्टॉल में चीजें कहां से आती हैं, इसके बारे में कुछ जानकारी आउटपुट करना शुरू करें! इससे कई समस्याओं का तत्काल समाधान हो सकता है।

यह बहुत उपयोगी होगा (नौसिखिया उपयोगकर्ताओं और अन्य प्लेटफार्मों के अनुभवी उपयोगकर्ताओं दोनों के लिए) कोई फर्क नहीं पड़ता कि आमंत्रण वाक्यविन्यास के बारे में निर्णय क्या है।

+1 pip.+ को पदावनत किए बिना pip $ को बहिष्कृत करने पर, लेकिन यह स्वचालन स्क्रिप्ट को ठीक करने के लिए बहुत अधिक काम नहीं होना चाहिए और वास्तव में मुझे लगता है कि स्वचालन को यह जानने से अधिक लाभ होगा कि वास्तव में अजगर का कौन सा संस्करण चलाना है से पीप। मैंने अभी तक सभी तर्कों को नहीं पढ़ा है, लेकिन मैं शायद और अधिक राय देने के लिए वापस आऊंगा

मेरा पहला गिटहब +1। मुझे लगता है कि दस्तावेज़ों पर विचार करना उचित है कि _don't_ अनुशंसा python -m pip त्रुटिपूर्ण है, क्योंकि यह आमंत्रण सामान्य नौसिखिया डेवलपर के लैपटॉप की तरह हाथ से चलने वाले पायथन इंस्टॉल पर विफलता के लिए बहुत कम प्रवण है।

मेरे दृष्टिकोण से: मैं इस परिवर्तन के लिए प्रेरणाओं के बारे में सहमत हूँ। django-admin चलाने के लिए गलत पायथन संस्करण का उपयोग करने वाले लोगों के साथ Django में बहुत सी समान समस्याएं हैं; पाइप और django-admin दोनों के लिए python -m दृष्टिकोण पर जाना इस मुद्दे को हल करने का एक शानदार तरीका होगा।

मेरी एकमात्र चिंता बुलेट प्वाइंट 2: 10 और अक्षर लिखने के लिए है। UX के दृष्टिकोण से, मैं बॉयलरप्लेट को पेश करने के बारे में चिंतित हूं जिसे _anything_ चलाने के लिए टाइप करने की आवश्यकता है। विशेष रूप से नए उपयोगकर्ताओं के साथ व्यवहार करते समय, "बस मुझ पर भरोसा करें" जादू मंत्र प्रारूप आदर्श नहीं है।

एक सुझाव (हालांकि इसमें PyPA के बजाय Python में बदलाव की आवश्यकता है): py (या कुछ अन्य शॉर्टहैंड) को python -m के लिए एक शॉर्टकट बनाएं। हां, इसका मतलब है कि अजगर को आमंत्रित करने के 2 तरीके हैं, लेकिन आप इसे "पीई रन मॉड्यूल, पायथन रन कोड" के रूप में बचाव कर सकते हैं। इसका दूसरा पहलू यह होगा कि यह केवल नए पायथन संस्करणों को लाभान्वित करेगा, जब तक कि इसे 2.7/3 पर बैकपोर्ट नहीं किया गया। [345]।

@ freakboy3742 हाँ, मेरा मतलब यह भी होगा कि फ्लेक 8, पेप 8, इत्यादि सभी को इस सम्मेलन में भी जाना चाहिए (जो इस तथ्य को देखते हुए कि पाइफ्लेक्स पाइथन के संस्करण पर बहुत निर्भर है, थोड़ा और समझ में आता है)। py को उन लोगों के लिए एक पैकेज के रूप में भी वितरित किया जा सकता है जो जल्दी ऑप्ट इन करना चाहते हैं, लेकिन यह py.test के py मॉड्यूल के साथ विरोध करता है, भले ही मुझे सही से याद हो।

केवल pip के बजाय python -m pip के लिए डिफ़ॉल्ट और पसंदीदा के रूप में वकालत करने पर +1।

मैं शुरुआती (बच्चों को भी) पढ़ा रहा हूं और काफी समय से पायथन को नए-नए परिचित करा रहा हूं। @dstufft के बिंदुओं के अलावा, जब आप वर्चुअलएन्व क्षेत्र में पहुंचते हैं तो सब कुछ जटिल हो जाता है क्योंकि उपयोग किया जा रहा पायथन सिस्टम पथ पर डिफ़ॉल्ट पायथन नहीं है। _विशेष रूप से_, अन्य पायथन वितरणों का उपयोग करने पर ये जटिलताएं और भी बदतर हो जाती हैं; उदाहरण के लिए एनाकोंडा पायथन के साथ, आप पाइप के बिना एक कोंडा एनवी बना सकते हैं (उदाहरण के लिए आप conda install pip को भूल जाते हैं) और फिर पथ पर पाइप खुशी से रूट एनवी में स्थापित होता रहता है न कि आपके कोंडा एनवी। वैज्ञानिक क्षेत्र में, बहुत से लोग एनाकोंडा पायथन को अपने पहले, डिफ़ॉल्ट पायथन के रूप में उपयोग कर रहे हैं।

इस परिदृश्य में, python -m pip ... का उपयोग करके आपको बताएगा कि _active_ पायथन में पाइप मौजूद नहीं है या नहीं।

असुविधा की धारणा के लिए, यह अन्य बहुत ही सामान्य आह्वानों को भी प्रतिबिंबित करता है, जैसे python -m pdb , python -m ipdb , python -m cProfile , python -m timeit , python -m pstats , python -m SimpleHTTPServer , python -m json.tool , python -m gzip , python -m filecmp , python -m zipfile , python -m encodings.* , python -m mimetypes , python -m tabnanny , python -m pydoc , python -m unittest , python -m calendar , और शायद दूसरों का एक समूह जिनके बारे में मुझे जानकारी नहीं है।

मुझे पूरा यकीन है कि यह बदलाव करने से शुरुआती लोगों को पीआईपी को समझाने में आसानी होगी। मुझे -m स्विच को pdb और cProfile के लिए किसी भी तरह से समझाना होगा, इसलिए यह परिवर्तन मेरे छात्रों के लिए एक शुद्ध सरलीकरण होगा। (वेनव को पढ़ाना भी बहुत आसान हो जाएगा यदि आपको बस इतना करना है कि सही पायथन निष्पादन योग्य कॉल करें और पथ और "सक्रियण" के साथ गड़बड़ न करें, लेकिन यह एक और समय के लिए एक गड़बड़ी है)

कम से कम उस मामले के लिए pip कमांड रखना उपयोगी होगा जिसमें यह सहज और (ज्यादातर?) स्पष्ट है: वर्चुअलएन्व के अंदर।

ऐसा करने से दस्तावेज़ीकरण जड़ता में भी मदद मिलेगी।

मुझे 'मूव पिप/ टू _पिप/ एंड मेक पिप.पी' काफी पसंद है। एक विकल्प के रूप में। यह व्यवहार्य लगता है, और पीआईपी/आज में घूमने वाले लोगों के लिए विघटनकारी होने पर, उपयोगकर्ता अनुभव को बेहतर बनाने के लिए इसके लायक है - खासकर जब से हम आज सार्वजनिक एपीआई की पेशकश नहीं करते हैं।

मैं पदावनत करने पर +0 हूं क्योंकि यह एक उपयोगकेस नहीं है जिसे मैंने कभी चलाया है। उपनाम से परिचित नहीं होने वाले उपयोगकर्ताओं के लिए अजगर -m का उपयोग करना बहुत अधिक अतिरिक्त टाइपिंग होगा।

चूंकि हम काफी लंबे बहिष्करण पथ को देख रहे हैं, क्या Python 2.6 के लिए हैक के साथ आना आवश्यक है? लंबे समय तक पर्याप्त बहिष्करण पथ मानते हुए, क्या हम यह नहीं मान सकते हैं कि पायथन 2.6 का इतना कम उपयोग होगा कि हैक की आवश्यकता नहीं है?

मुझे लगता है कि मैं @audreyr से सहमत हूं - एक वर्चुअलएन्व में, यह स्पष्ट है, अलंकृत है (नहीं pip2 / pip3 /etc), और टूलिंग की पायथन परत ( activate , et । अल।) इसे बनाता है ताकि आप उपयोगकर्ताओं को उनके गोले को कॉन्फ़िगर करने के लिए बताए बिना "सही" बाइनरी प्राप्त कर सकें।

हालांकि मेरे पास और भी अधिक मौलिक प्रस्ताव है: क्या होगा यदि आपने इंस्टॉलर के रूप में pip भी नहीं चलाया? अक्सर, मैं जो चाहता हूं वह है virtualenv --requirement project/requirements.txt project ; अगर मैं एक नई चीज़ को "इंस्टॉल" करना चाहता हूं, तो यह एक नए वर्चुअलएन्व का समय है। बेशक मैं इस नियम को हर समय तोड़ता हूं, मौजूदा वेनव्स को अपग्रेड करता हूं, निर्भरता को दूर करता हूं, लेकिन यह ज्यादातर एक बुरी आदत है जिससे मुझे लगता है कि मुझे इससे छुटकारा पाना चाहिए, खासकर अब जब पहिये नए-वर्चुअल-निर्माण को काफी तेज बनाते हैं।

pip एक कमांड लाइन के रूप में वास्तव में अच्छा है। वर्चुअलएन्व के बारे में अभी तक कोई नहीं जानता है, और कुछ उपयोगिताएं हैं जिन्हें आप वर्चुअलएन्व के बाहर उपयोग करना चाहते हैं। क्या होगा यदि मैं नवीनतम Mercurial या Stackless Python को pip के साथ स्थापित करना चाहता हूं, तो मैं इसे अभी कर सकता हूं।

मैं पहली कोशिश में कभी भी npm/bower भस्म नहीं प्राप्त कर सकता। यहां तक ​​​​कि अगर आप निष्पादन योग्य को हटा देते हैं, तब भी कोई नेट में लटके कुछ पुराने दस्तावेज़ों को देखेगा, और ओएस प्रदान किए गए पायथन-पाइप और/या पायथन 3-पाइप का उपयोग करेगा, और यह असफल हो जाएगा। फिर वह कोई अभी भी sudo pip install -U someoldpackageyoudontwanttoupgrade की कोशिश करेगा और ओह, ओएस आप पर चिल्ला रहा है। हाँ, मैंने ऐसा किया है। इसे केवल sudo python -m pip से बदलने से इस स्थिति से बचा नहीं जा सकेगा।

पैकेज (और स्वयं) के बारे में पाइप व्यवहार बनाने पर ध्यान केंद्रित करना आसान नहीं होगा - डिफ़ॉल्ट रूप से उपयोगकर्ता इंस्टॉल करने योग्य, फिर pip2/pip3/जो भी नवीनतम पाइप के लिंक के साथ से छुटकारा पाएं/बदलें, ताकि यह पहले मिल जाए उपयोगकर्ता का पथ (मेरे पास पहले से ही मेरा है ~/.local/bin/ ), अपने स्वयं के पहिये से काम कर रहा है, और जो कुछ भी ओएस "सबसे अच्छा सोचता है" से सुरक्षित रूप से टकरा गया है। मैंने पीआईपी को वर्चुअलएन्व के साथ काम करने की अनुमति देने के लिए एक वर्कअराउंड सबमिट किया है जब यह डिफ़ॉल्ट रूप से उपयोगकर्ता इंस्टॉल पर सेट होता है (https://github.com/pypa/virtualenv/issues/802) जो pyenv के साथ भी काम करता है।

यह उन लोगों के लिए है जो वास्तव में परवाह नहीं करते हैं कि वे किस पायथन संस्करण के साथ काम कर रहे हैं, और कुछ "बस काम" करना चाहते हैं। तब कुछ व्यवस्थापक अभी भी "सभी के लिए sudo pip install" का उपयोग करना चाहेंगे और यह बस काम करता है। उपयोगकर्ता बस "मेरे लिए पाइप इंस्टॉल" करने का प्रयास करता है और यह सिर्फ काम करता है।

इसके बजाय मुझे "/whereismypython/python -m pip install -g --userDev --Ireallymeanit --कृपयाlistentome blah" के बारे में चिंता करने की ज़रूरत नहीं है। और "python setup.py install blah" पर वापस जाना मुझे एक कदम पीछे की तरह लगता है।

-1 मुझ से pip और इसके संस्करण विशिष्ट सिम्लिंक को छोड़ने पर, क्योंकि पदावनति की छड़ी को _very_ हल्के से चलाने की आवश्यकता होती है।

पायथन पारिस्थितिकी तंत्र में परिवर्तन थकान के साथ हमारे पास पहले से ही एक महत्वपूर्ण समस्या है, क्योंकि तीन प्रमुख निम्न स्तर के तकनीकी संक्रमण हैं (पायथन 2 -> पायथन 3, easy_install/अंडे -> पाइप/पहिए, डिफ़ॉल्ट रूप से असुरक्षित -> डिफ़ॉल्ट रूप से सुरक्षित) अभी भी प्रगति पर है, और पुनर्वितरण चैनलों के माध्यम से उन्हें प्रचारित करने में काम का एक _lot_ शेष है (प्रत्यक्ष अपस्ट्रीम उपभोक्ता जो वास्तव में हमसे ऑनलाइन बात करते हैं, जब यह पायथन के उपयोगकर्ता आधार की बात आती है तो हिमशैल की नोक होती है)। उसके ऊपर एक "पाइप" -> "पायथन-एम पाइप" संक्रमण जोड़ना अभी दर्द के लायक नहीं है (एक मोटे अनुमान के रूप में, मैं कहूंगा कि उस पर मेरी राय 2017 तक बदल सकती है)।

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

1. यह किस पायथन संस्करण के लिए स्थापित कर रहा है
2. सुझाव देता है "-एम पिप" एक विशिष्ट स्थापना को लक्षित करने के लिए

उदाहरण के लिए:

"रनटाइमवार्निंग: '/usr/lib/python2.7/site-packages' में इंस्टॉल करते हुए कोई वेनव नहीं मिला। उपयोगकर्ता-विशिष्ट इंस्टॉलेशन के लिए '--user' पास करें, या किसी भिन्न को लक्षित करने के लिए '<other_python> -m pip' चलाएं। रनटाइम"।

मुझे अजगर को बांधने का अवसर भी दिखाई देता है -> py संक्रमण को पायथन 2->3 प्रवास में, लेकिन यह यहाँ के बजाय अजगर-विचारों का विषय है।

@cjrh +1 python -m pip की वकालत करने के लिए विशेष रूप से नए परिनियोजन (विशेष रूप से विज्ञान और डेटा विज्ञान के साथ-साथ शिक्षा) के लिए एक PyPA पसंदीदा इंस्टॉल के दस्तावेज़ीकरण में। कोंडा और ब्रू जटिल चीजों के रूप में कालेब का उल्लेख है।

वर्चुअलएन्व में @audreyr से सहमत हैं।

संक्रमण शुरू में प्रलेखन हो सकता है। @ncoghlan मुझे लगता है कि कई क्रमपरिवर्तन के माध्यम से अंतिम उपयोगकर्ताओं को चलने के लिए डेटा विज्ञान/विज्ञान में तीसरे पक्ष की परियोजनाओं के अनुरक्षकों द्वारा पहले से ही पीआईपी/कोंडा/काढ़ा समस्या निवारण की एक महत्वपूर्ण राशि है। मैं सहमत हूं कि बेहतर चेतावनियां देना भी मददगार होगा।

python -m pip install ...
वर्चुअलएन्व में pip install

मुझे वास्तव में @glyph का सुझाया गया virtualenv --requirement project/requirements.txt project . भी पसंद है

दरअसल, तीनों दृष्टिकोण निष्पादन में संस्करण संख्याओं पर जोर देते हैं। यह वास्तव में कुछ परियोजनाओं को पायथन 3 में ले जाने की दिशा में एक अप्रत्याशित लाभ हो सकता है।

-1 पाइप हटाने पर मुझे अपनी सभी परिनियोजन स्क्रिप्ट बदलनी होगी।
pipX और pipX.Y . को हटाने पर +1

मेरे कारण यह हैं कि मेरे पास पाइप का उपयोग करने के लिए मूल रूप से 2 उपयोग के मामले हैं (जो कुछ हद तक पहले से ही @audreyr और अन्य लोगों द्वारा उल्लेख किया गया है लेकिन मैं दोहराऊंगा):

1. मैं वर्चुअलएन्व के अंदर हूं और मुझे पता है कि मैं कौन सा पायथन निष्पादित करना चाहता हूं (और निष्पादित होगा): वर्चुअलएन्व का पायथन जिसे मैंने वर्चुअलएन्व के निर्माण के समय चुना था
2. मैं एक पैकेज स्थापित करना चाहता हूं जो मेरे वितरण द्वारा प्रदान नहीं किया गया है और ऐसा करने के लिए पाइप का उपयोग करेगा, इस मामले में मुझे वास्तव में परवाह नहीं है कि मैं किस पायथन का उपयोग कर रहा हूं, मैं डिफ़ॉल्ट सिस्टम-व्यापी पायथन का उपयोग कर रहा हूं।

मुझे एहसास है कि ये सिर्फ मेरे व्यक्तिगत उपयोग के मामले हैं, लेकिन मेरा मानना ​​​​है कि वे पाइप का उपयोग करने वाले लोगों में काफी आम हैं।
मैंने केवल pip3 का उपयोग कुछ python3-only संकुल सिस्टम-व्यापी स्थापित करने के लिए किया है जो एक उपयोग-मामला है जो धीरे-धीरे (शायद प्रस्तावित बहिष्करण चेतावनी से तेज़) गायब हो जाना चाहिए क्योंकि वितरण धीरे-धीरे आगे बढ़ रहे हैं डिफ़ॉल्ट रूप से python3।

और इस टिप्पणी को बंद करने के लिए, मैं वर्चुअलएन्व के अंदर और बाहर एक अलग सिंटैक्स का उपयोग करने के लिए नहीं हूं, यह बहुत सारे लोगों के लिए भ्रमित करने वाला होगा (cf। @Samureus टिप्पणी कि npm कितना भ्रमित है)

कैसे एक नए आदेश के माध्यम से पाइप प्रदान करने के बारे में जो केवल python -m pip . को स्थगित करता है

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

विशेष जांच के लिए सुझाव।

1. यदि पाइप सीधे पथ के माध्यम से निष्पादित किया जा रहा है, तो इस चेक को पूरी तरह से अनदेखा करें। उदाहरण के लिए वेनव/बिन/पाइप इस चेक को ट्रिगर नहीं करेगा।
2. प्रत्येक पीआईपी नाम के लिए "समकक्ष पायथन नाम" परिभाषित करें। यदि पाइप नाम 'पाइप' से शुरू होता है तो यह pipname.replace("pip", "python", 1) है। यानी हम सिर्फ प्रत्यय को अजगर में स्थानांतरित करते हैं, इसलिए pip2 -> python2, pip3.4 -> python3.4, आदि। यदि पाइप नाम 'पाइप' से शुरू नहीं होता है तो यह सिर्फ 'अजगर' होने के लिए डिफ़ॉल्ट है।
3. यदि संबंधित पायथन लुकअप और कैनोनिकलाइज़िंग पथ करने के बाद sys.executable के बराबर नहीं है, तो चेतावनी बढ़ाएँ। इसे कुछ इस तरह कहना चाहिए "चेतावनी: पाइप पथ पर की तुलना में एक अलग अजगर में स्थापित हो रहा है। आप शायद {pythonname} -m pip.{__main__ अगर यह 2.6}" चलाना चाहते हैं, तो इससे बेहतर सोचा जा सकता है। :-)

@ncoghlan और @DRmacIver . की टिप्पणियों के लिए +1

चूंकि यहां समस्या "कभी-कभी लोग भ्रमित होते हैं", क्या हम मूल रूप से प्रत्येक पायथन प्रोजेक्ट के रीडमे को पहले चरण के रूप में बदलने की कोशिश करने के बजाय कुछ उपयोगी लॉग संदेशों/चेतावनियों से शुरू कर सकते हैं?

क्या कहीं पाइप का उपयोग करने के लिए "अनुशंसित सर्वोत्तम अभ्यास" हैं? जैसे, "डेबियन पर, केवल python-virtualenv और python-dev स्थापित करें और फिर पाइप प्राप्त करने के लिए हमेशा वर्चुअलएन्व का उपयोग करें" (या जो भी सर्वोत्तम अभ्यास वास्तव में माना जाता है)।

साथ ही, यदि मुख्य मुद्दा यह है कि "जब 'पायथन' 'पाइप' बिंदुओं से अलग होता है, तो बुरी चीजें होती हैं" क्या किसी प्रकार की डरावनी चेतावनी का पता लगाना और जारी करना संभव नहीं है? या --do-the-bad-things या कुछ के बिना भी काम करने से मना कर दिया?

python -m pip install ... टाइप करने के लिए अतिरिक्त कीस्ट्रोक्स के अलावा, क्या अंतिम उपयोगकर्ता (वैज्ञानिक और डेटा वैज्ञानिक) इस दृष्टिकोण का उपयोग करने की अनुशंसा नहीं करने का कोई तकनीकी कारण है?

@willingc afaik यह कमांड ubuntu को छोड़कर हर जगह काम करता है

@nanuxbe धन्यवाद। उबंटू बाधा क्या है?

@willingc पायथन 2.6 पर काम नहीं करता है। उम्मीद है कि कोई समस्या नहीं है, लेकिन यह कुछ लोगों के लिए हो सकता है।

@willingc सुनिश्चित नहीं है कि बाधा क्या है, लेकिन वे इसे virtualenv के साथ भी करते हैं।
$ python -m pip install --upgrade pip
/usr/bin/python: cannot import name defaultdict; 'pip' is a package and cannot be directly executed

+1 जो @ncoglan ने ऊपर कहा है।

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

@willingc उबंटू 14.04 (वर्तमान एलटीएस) पर, पाइप को एक अलग उबंटू पैकेज में बनाया गया है जिसे ओएस पैकेज मैनेजर के साथ स्थापित किया जाना है। AFAICR यह python2 और python3 के लिए समान है। पायथन 3 के लिए, वेनव को ओएस द्वारा भी हटा दिया गया है और ओएस पैकेज में बनाया गया है। जैसे @nanuxbe बताते हैं, अपेक्षित आदेश काम नहीं करते हैं, उदाहरण के लिए python3 -m venv भी। और फिर यदि आप पाइप को अपग्रेड करते हैं (I _think_ केवल py2 पर), तो आपको InsecurePlatformWarning संदेश मिलता है। ये सभी ज्ञात और जटिल मुद्दे हैं, जिनसे पिप प्रोजेक्ट पर काम करना बहुत कठिन और निराशाजनक होना चाहिए, और मैं उनकी कड़ी मेहनत के लिए उन्हें धन्यवाद देता हूं। हर कोई शिकायत करता है जब सबसे छोटी अनपेक्षित चीज होती है, जबकि कोई भी खुश नहीं होता जब चीजें "बस काम करती हैं"। मैं यह जानने का नाटक नहीं कर सकता कि सभी मुद्दे क्या हैं, और जिनके बारे में मुझे पता है, मैं भी पूरी तरह से समझ नहीं पा रहा हूं। ये कठिन समस्याएं हैं और मैं उन लोगों के लिए विस्मय और आभार व्यक्त करता हूं जो इनसे निपटने का विकल्प चुनते हैं।

wrt python -m pip बनाम pip : मैं अपना वोट "चीजों को यथावत रहने" के लिए बदल रहा हूं।

मैंने यह सुनिश्चित करने के लिए जाँच की और ऐसा लगता है कि अभी conda स्वचालित रूप से किसी भी नए env में pip जोड़ देगा, 2.6 सभी तरह से 3.5 (मुझे उम्मीद है कि यह सभी प्लेटफार्मों पर ऐसा करेगा)। तो जिस मामले का मैंने पहले उल्लेख किया था कि pip को एक conda env में स्थापित करना भूल गया था, वह अब नहीं हो सकता है (इसलिए आपके पास गलत conda env में एक पाइप चलाने की स्थिति नहीं हो सकती है)।

केवल विंडोज़ समस्या शेष है कि वर्तमान में आप pip को pip $ के साथ अपग्रेड नहीं कर सकते हैं, लेकिन यह एक छोटी सी समस्या है क्योंकि conda upgrade pip ठीक काम करता है। अगर हम विंडोज़ पर गैर-कोंडा उपयोगकर्ताओं के लिए बहुत उदार बनना चाहते हैं, तो हम pip install -U pip के लिए पता लगा सकते हैं और केवल एक संदेश दे सकते हैं जो कहता है। "विंडोज कैसे काम करता है, इस वजह से, पाइप खुद को चालू करते समय बंद कर दिया जाता है ताकि आप इस तरह से पाइप को अपग्रेड नहीं कर सकें। इसे इस तरह से करें: python -m pip install -U pip ", और यह पूरी तरह से पर्याप्त होगा।

मुझे नहीं लगता कि एक और अत्यधिक दृश्यमान परिवर्तन के सभी दर्द लंबे समय में मामूली लाभ होने वाले हैं।

wrt pipX.Y : शीर्ष पोस्ट में दी गई सभी समस्याओं के कारण मैंने कभी उपयोग नहीं किया है, और न ही उनके उपयोग पर भरोसा किया है। मेरी यहां कोई राय नहीं है क्योंकि यह मुझे प्रभावित नहीं करता है। मैं कहना चाहता हूं "उनसे छुटकारा पाएं" लेकिन मुझे नहीं पता कि कौन प्रभावित है।

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

व्यक्तिगत रूप से मुझे परिवर्तन-थकान तर्क कुछ सम्मोहक लग रहा है

मैं सहमत हूं। मुझे नहीं पता था कि अन्य लोग इससे थके हुए थे (मुझे लगता है कि जब से मैं ध्यान देता हूं, इससे मुझे थकान नहीं होती)।

ऐसा कुछ ऐसा लगता है जिसे थोड़ी देर के लिए बंद कर देना चाहिए

वैसे मूल अंक में लिखे गए बहिष्करण के लिए समय की लंबाई "वर्षों के क्रम पर" थी। मुझे लगता है कि इस बीच लोगों को धीरे-धीरे python -m pip की ओर ले जाना शुरू करने से कोई नुकसान नहीं होगा। pip , pipX.Y , आदि तुरंत गायब नहीं होंगे।

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

क्या किसी को, शायद मुझे, पीईपी के रूप में प्रस्तावित करना चाहिए कि "पायथन इंस्टॉल" "पायथन-एम पीआईपी" के लिए उपनाम हो?

पायथन 3.4 में पीईपी 453 से शुरू करना, अगर मैं सही ढंग से समझूं, तो अजगर को स्थापित करने में पाइप स्थापित करना शामिल है। तो यह पाइथन निष्पादन योग्य के लिए "पायथन इंस्टॉल ..." की तरह शुरू होने पर पाइप को आमंत्रित करने के लिए एक व्यवहार्य कदम प्रतीत होता है।

अगर यह किसी को भी बेहतर महसूस कराता है, ऐसा नहीं है कि कोंडा भूमि में सब कुछ बारहमासी सदाबहार है, मेरे मैक पर conda वर्तमान में बंद हो गया है क्योंकि एक एनवी के निर्माण में उपयोग की जाने वाली आधारभूत संरचना स्क्रिप्ट में से एक निष्पादन योग्य बिट खो गया है हाल के एक अद्यतन में;)

आपकी अंतर्दृष्टि के लिए सभी का धन्यवाद। उबंटू के लिए @cjrh उत्कृष्ट स्पष्टीकरण पढ़ने के बाद, मैं थकान से उबरने के साथ शांत हूं। FWIW, कोंडा के पुराने इंस्टॉलेशन पैकेज के लिंक और पथ को गड़बड़ कर सकते हैं जैसा कि हमने DjangoCon DjangoGirls में पाया। हमें अनिवार्य रूप से एनाकोंडा और पायथन को पूरी तरह से अनइंस्टॉल करने की जरूरत है, फिर अजगर को फिर से स्थापित करें और पाइप को DjangoGirls पैकेज स्थापित करें।

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

@ajdavis

पायथन 3.4 में पीईपी 453 से शुरू करना, अगर मैं सही ढंग से समझूं, तो अजगर को स्थापित करने में पाइप स्थापित करना शामिल है।

जब तक आप एक सामान्य लिनक्स डिस्ट्रो पायथन का उपयोग नहीं कर रहे हैं: डी

btw python -m pip टाइप करने के लिए python install से 1 वर्ण कम है। मुझे इसके किसी भी लाभ के बारे में निश्चित नहीं है, साथ ही यह शब्दार्थ रूप से भ्रमित होना संभव है - python install uninstall ... , python install -U pip ?

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

जहां तक

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

मुझे किसी बड़े अंतर की जानकारी नहीं है? इसके अलावा विंडोज़ को हमेशा पाइप को python -m के साथ अपग्रेड करने की आवश्यकता होती है जैसा कि पहले बताया गया था। हालांकि, यह ज्यादातर खिड़कियों का एक टुकड़ा है।

यह भी ध्यान देने योग्य है कि मेरा मानना ​​​​है कि बहुत सी अन्य वर्तमान जटिलता वास्तव में पाइप के काम करने के तरीके में निहित होने के बजाय, पायथन 2-> 3 संक्रमण से संबंधित है। विशेष रूप से, लिनक्स और अन्य * निक्स सिस्टम पर एक सिस्टम पायथन 3 स्टैक को किसी भी अन्य पायथन वातावरण (चाहे वह विंडोज इंस्टाल, वर्चुअल वातावरण या कोंडा वातावरण हो) से अलग-अलग कमांड (पायथन 3, पीआईपी 3) की आवश्यकता होती है।

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

एक विचार जो मैं अब सुझाव दे रहा हूं, वह है विंडोज के लिए पायथन लॉन्चर के व्यवहार से मेल खाने के लिए उपयोगकर्ता-कॉन्फ़िगर करने योग्य "पीई" शॉर्टहैंड की शुरूआत: https://mail.python.org/pipermail/linux-sig/2015- अक्टूबर/000000.html

@lvoz हाँ, अतीत से बहुत अधिक प्रदूषण। FWIW, Django गर्ल्स इंस्टाल इश्यू ने खुद को, @honzakral और @jambonrose को समस्या निवारण और समाधान के लिए 30-45 मिनट का अच्छा समय दिया। 3 अनुभवी डेवलपर्स के लिए यह स्पष्ट नहीं था कि क्या हो रहा था।

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

चर्चा के लिए देखें https://mail.python.org/pipermail/distutils-sig/2015-November/027536.html ।

-1 दूसरों को छोड़ने के लिए पीआईपी +1 छोड़ने के लिए

चूंकि pip 10.0, Py2.6 के लिए समर्थन छोड़ता है, मैं अभी इस मुद्दे पर अभी एक बार प्रहार करना चाहता हूं।

मैं कहूंगा कि उस पर मेरी राय 2017 तक बदल सकती है

पिंग @ncoghlan? :)

पाइप/ को _pip/ पर ले जाएं

यह किया गया है, यद्यपि pip._internal के रूप में। #4700

हम संभवतः शेल उपनामों के माध्यम से पाइप, पाइपएक्स, और पीआईपीएक्स.वाई को पुनर्स्थापित करने के लिए दस्तावेज़ों में एक नुस्खा पेश कर सकते हैं।

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

एक अन्य विकल्प यह होगा कि पाइप को उसी पायथन वातावरण में निष्पादित करने की आवश्यकता को रोकना होगा जिसमें वह चीजों को स्थापित कर रहा है ...

मुझे @dholth का यह आइडिया भी पसंद है। थोड़ा सुरक्षित होने के लिए इसमें शायद #4145 जैसा कुछ भी होना चाहिए।

कई लिनक्स डिस्ट्रो अब डिफ़ॉल्ट रूप से एक अयोग्य pip शिप नहीं करते हैं, क्योंकि वे डिफ़ॉल्ट रूप से python2 शिप नहीं करते हैं। तो इस बिंदु पर मेरी प्राथमिकता:

एक सक्रिय आभासी वातावरण के अंदर , मुझे लगता है कि कम से कम एक अयोग्य pip को काम करना जारी रखना चाहिए, और सक्रिय आभासी वातावरण को प्रभावित करना चाहिए। उस स्थिति में यह स्पष्ट नहीं है, इसलिए इसे तोड़ने से किसी भी मौजूदा उपयोगकर्ता दर्द से बचा नहीं जा सकता है। मैं pipX , और pipX.Y ( X.Y venv में पायथन के संस्करण से मेल खाने के साथ) पर अधिक महत्वाकांक्षी हूं, क्योंकि उस पर भरोसा करने से पायथन के एक अलग संस्करण में अपग्रेड हो जाता है जरूरत से ज्यादा कठिन है, और एक आभासी वातावरण के अंदर पूरी तरह से बेमानी है।

एक सक्रिय आभासी वातावरण के बाहर , मुझे लगता है कि यह अधिक सक्रिय रूप से उन्हें हतोत्साहित करने और python -m pip की सिफारिश करने के लिए समझ में आता है। यह अनिवार्य रूप से पायथन रनटाइम के लिए एक प्लगइन प्रबंधक के रूप में पिप की स्थिति पर जोर देता है और जो कुछ समय के लिए हमारे पास मानक पुस्तकालय डॉक्स में है (https://docs.python.org/3/installing/#basic-usage) के साथ संरेखित करता है। .

संपादित करें: सक्रिय आभासी वातावरण के अंदर पायथन-संस्करण-योग्य नामों के बारे में मेरी महत्वाकांक्षा का उल्लेख किया।

मुझे लगता है कि एक आभासी वातावरण के अंदर और एक आभासी वातावरण के बाहर विभिन्न आदेशों की सिफारिश करना भ्रामक है (और एक दर्द, हम इसे pypi.org कहने पर कैसे करते हैं?) हम यहां जो कुछ भी करते हैं, आधिकारिक तौर पर अनुशंसित तंत्र के रूप में कमांड का एक सेट होना चाहिए।

मैं python -m pip का उपयोग करने के पक्ष में लगातार अनुशंसाओं के साथ ठीक हूं, केवल एक चीज जो मैं ठीक नहीं हूं वह वास्तव में pip install को एक सक्रिय वर्चुअलएन्व के अंदर तोड़ रहा है - यह अस्पष्ट नहीं है, और यह काम करता है क्रॉस-प्लेटफ़ॉर्म (शायद विंडोज़ पर पाइप को अपग्रेड करते समय छोड़कर)।

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

ठीक है, मैं एक स्क्रिप्ट प्रविष्टि बिंदु के संदर्भ में सोच रहा था जो हमेशा स्थापित किया गया था, लेकिन अगर आप इसे वर्चुअल वातावरण के बाहर चलाने की कोशिश करते हैं तो भी हमेशा विफल रहता है (यानी यह "यहां कोई फ़ाइल नहीं" परिदृश्य के बजाय रनटाइम चेक होगा)

-1 पिप छोड़ने पर। अधिकांश उपयोगकर्ता जिन्हें मैंने देखा है, उनमें आमतौर पर एक ही इंस्टॉलेशन होता है (कोंडा में पायथन 3.6 है), और इसका उस दृष्टिकोण से कोई मतलब नहीं है। एकमात्र समस्या पायथन 2 समस्या है और यह अपेक्षाकृत जल्द ही दूर होने लगेगी।

तो, अब हम ऐसी स्थिति में हैं जहाँ हम Python 2.6 का समर्थन नहीं करते हैं। तो python -m pip हर जगह काम करता है और मैं इसे डॉक्स में पाइप चलाने के विहित तरीके के रूप में उपयोग करने के पक्ष में हूं (और हां, यूनिक्स पर python2/python3 है, और py विंडोज़ पर, लेकिन हम शायद उस हिस्से को काम करने के लिए उपयोगकर्ताओं पर भरोसा कर सकते हैं)।

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

एक विकल्प यह हो सकता है कि स्क्रिप्ट रैपर को अपने स्वयं के पैकेज pip-cli या उसके जैसा कुछ स्थानांतरित किया जाए, और बस इसे उन पैकेजों की सूची में शामिल किया जाए जो वर्चुअल वातावरण डिफ़ॉल्ट रूप से स्थापित होते हैं।

हम पाइप 10 जैसे मामलों को कैसे संभालेंगे, जहां पाइप 9 और पाइप 10 का समर्थन करने के लिए पाइप-क्ली के विभिन्न संस्करणों की आवश्यकता होती है (क्योंकि pip.main ले जाया गया)? यदि उपयोगकर्ता पीआईपी को अपग्रेड करता है, तो हमारे पास पीआईपी-क्ली को अपग्रेड करने के लिए बाध्य करने का कोई साधन नहीं है। तो हम उसी ब्रेकेज के साथ समाप्त होंगे जो हम वर्तमान में ओएस रैपर के साथ देखते हैं।

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

यदि हम पाइप-क्ली मार्ग से नीचे जाना चाहते हैं, और हम उप-प्रक्रिया दृष्टिकोण को उचित नहीं ठहरा सकते हैं, तो या तो हमें पाइप-क्ली को पाइप के आंतरिक का उपयोग करने के लिए एक छूट देने की आवश्यकता है, या हमें औपचारिक रूप से pip.main को उजागर करने की आवश्यकता है।

पाइप-क्ली का उपयोग करना pip.__main__.main ठीक होना चाहिए।

या बस रनपी का उपयोग करें: https://docs.python.org/2/library/runpy.html , यह वही है जो -m वैसे भी उपयोग करता है।

रनपी का उपयोग करने पर +1।

रनपी का उपयोग करने पर +1।

ठीक वैसा ही। :)

टीआईएल लगभग runpy ।

आपका मतलब https://docs.python.org/3/library/runpy.html है, है ना? :मुस्कुराना:

@ Juanlu001 हम अभी भी Python 2.7 का समर्थन कर रहे हैं। :)

#5508 पर कुछ और चर्चा है ( @dstufft ने बताया कि यह इस मुद्दे का एक डुप्लिकेट था!)

व्यक्तिगत रूप से, मुझे लगता है कि यहां उल्लेखित भ्रम का एक बड़ा स्रोत बेमेल pip बनाम python -m pip है।

ISTM यह कुछ ऐसा है जिसे sys.executable और PATH का उपयोग करके जांचा जा सकता है। इसके अतिरिक्त, पाइप को पथ (जैसे bin/pip ) के माध्यम से बुलाए जाने पर चेतावनी/विफल नहीं होना चाहिए जिसे sys.argv[0] का उपयोग करके चेक किया जा सकता है। मैं यहां जो एज-केस देख रहा हूं वह है: एक ओएस पर जहां sys.argv[0] स्क्रिप्ट को लागू करने के लिए उपयोग किए जाने वाले से कुछ अलग है। AFAICT, यह Windows या MacOS 10.13 (हाई सिएरा) पर कोई समस्या नहीं है।

यह करना एक अच्छी बात होनी चाहिए, भले ही हम pip* रैपर को हटाने का निर्णय लें या नहीं। क्या मुझसे कोई चूक हो रही है?

मुझे लगता है कि आप यहां जो खो रहे हैं वह यह है कि अधिकतर, प्रश्न में pip निष्पादन योग्य डिस्ट्रो द्वारा भेजे गए हैं, जो पाइप अपडेट नहीं कर सकता है (एक कारण या किसी अन्य कारण से - अनुमतियां, इसके अलावा किसी अन्य स्थान पर स्थापित जहां एक सामान्य pip install जाता है, PATH उपयोगकर्ता बनाम सिस्टम इंस्टाल, आदि के आसपास जारी करता है)।

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

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

कुछ अनुशंसित समस्या निवारण चरणों को निष्पादन योग्य नुस्खा में बदलने की चर्चा के लिए https://github.com/pypa/python-packaging-user-guide/issues/396 देखें।

वह रैपर स्क्रिप्ट हमारे स्वामित्व में है। वे केवल उसी का उपयोग कर रहे हैं जिसे हम उत्पन्न कर रहे हैं, परिवर्तन को बाहर आने में बस एक लंबा समय लगेगा।

मुझे जो मिल रहा था वह यह है कि वे इसे स्थापित नहीं करते हैं जहां हम उनसे उम्मीद करते हैं (AFAIK, यही कारण है कि sudo pip install -U pip रैपर के साथ टूट जाता है जो अभी भी pip.main की तलाश में है)। अतिरिक्त तर्क यह भी है कि हमें अलग-अलग सिस्टमों को संभालने के लिए रैपर में डालने की आवश्यकता हो सकती है, जिसमें सिस्टम-वाइड के साथ-साथ उपयोगकर्ता-साइट में पाइप स्थापित है, और यह यकीनन हमारी वर्तमान स्क्रिप्ट में एक बग है - हालाँकि जहाँ तक मुझे पता है स्थिति इतनी उलझी हुई है कि मैंने कभी भी इस बात का अच्छा उदाहरण नहीं देखा कि कैसे उस राज्य में पुनरुत्पादित रूप से प्रवेश किया जाए ...

@ncoghlan उस मुद्दे के उस क्रॉस-रेफरेंस के लिए धन्यवाद। :)

@pfmoore यह समझ में आता है और मुझे लगता है कि रैपर को _pip_ से अलग करना पैकेज उपयोगी होगा; क्या यह पूरी तरह से हटाना है या इसे _pip-cli_ पैकेज में ले जाना है।

मैंने कुछ ऐसा लाने की कोशिश की जो यथास्थिति के साथ इस मुद्दे में उठाई गई सभी चिंताओं (लगभग) को संतुष्ट करता हो। मुझे लगता है कि समाप्त करने के लिए एक अच्छी स्थिति होगी:

• _pip_ कोई CLI रैपर प्रदान नहीं करता है; केवल python -m pip का समर्थन करता है
• _pip-cli_ python -m pip प्रक्रिया में pip आवरण के रूप में नकल करता है
• _virtualenv_ के इंस्टाल-बाय-डिफॉल्ट पैकेज में _pip-cli_ शामिल करें

यहाँ विकल्पों के लिए तर्क:

• वर्चुअलएन्व के अंदर उपयोग में आसानी; यह अभी भी pip है।
• विंडोज अपग्रेड यूएक्स में सुधार
  
  
  
  • pip install --upgrade pip विंडोज़ पर काम करेगा :टाडा:
  
  
  • हालांकि अभी भी python -m pip install --upgrade pip-cli करने की आवश्यकता होगी
  
  
  • किसी समस्या से थोड़ा कम क्योंकि उसके अपडेट बहुत कम बार-बार हो सकते हैं
  
  
• मौजूदा दस्तावेज कहता है "पाइप इंस्टॉल ..." जो अभी भी वेनव में काम करेगा।
• pipX और pipX.Y . प्रदान नहीं करना
  
  
  
  • वे virtualenv + ओपी में सूचीबद्ध मुद्दों में बेमानी हैं; वे अच्छी तरह से स्केल नहीं करते हैं
  
  
  • थोड़े तरह से डिस्ट्रो के निष्पादन योग्य के साथ एक हद तक विरोध करने से बचें (जब डिस्ट्रो अयोग्य रूप प्रदान नहीं करता है)
  
  

उपरोक्त पर इनपुट और टिप्पणियों का स्वागत है।

अन्य नोट:

• मुझे pipX और pipX.Y के लिए कोई सम्मोहक तर्क नहीं दिख रहा है। उन्हें शायद बहिष्कृत/हटा दिया जाना चाहिए।
• संबंधित: #4625 (मौजूदा रैपरों को अधिलेखित करना)
  
  
  
  • यहां प्रासंगिक: यह _pip-cli_ इंस्टॉलेशन को डिस्ट्रो-इंस्टॉल किए गए पिप्स के साथ अच्छा व्यवहार करेगा
  
  
• python -m pip और pip की "सैनिटी चेक" चेकिंग तुल्यता होने के कारण, _pip-cli_ के एक भाग के रूप में मुझे आकर्षक लगता है।

@pradyunsg कुल मिलाकर, यह मेरे लिए एक अच्छी योजना की तरह लग रहा है।

मेरी ओर से @pradyunsg की योजना के लिए +1।

pipX के एक मामले के बारे में मुझे पता है कि लिनक्स सिस्टम पर pip3 install --user ... का उपयोग होता है, लेकिन इसके बजाय इसे python3 -m pip install --user ... में बदलना बहुत अधिक बोझ नहीं है।

अगर डिस्ट्रोस ने फैसला किया कि वे रैपर स्क्रिप्ट को अपने python2-pip और python3-pip पैकेज में बैकवर्ड संगतता कारणों से जोड़ना चाहते हैं, तो मुझे भी लगता है कि हम इसके साथ ठीक रहेंगे।

मुझे लगता है कि रणनीति बहुत सीधी होगी pipX , pipX.Y :

1. रिलीज नंबर
   
   
   
   • पदावनत pipX , pipX.Y ; उपयोग किए जाने पर हटाने के बारे में चेतावनी दिखाता है।
   
   
2. रिलीज़ n+1 (या n+2)?
   
   
   
   • _pip_ से pipX , pipX.Y निकालें।
   
   

यह इतना सीधा है कि मुझे लगता है कि हम n को यहां 18.0 होने दे सकते हैं; अगले महीने किसी समय निर्धारित। यहां केवल एक चीज होगी: हम कब तक बहिष्करण चलाते हैं? मैं उस पर बाड़ पर हूँ।

pip के लिए, यह और दिलचस्प हो जाता है। मुझे पूरा यकीन है कि हम नहीं चाहते कि यह परिवर्तन उपयोगकर्ता के वर्कफ़्लोज़ के लिए अत्यधिक विघटनकारी हो _और_ _pip-cli_ में संक्रमण के लिए एक आसान तरीका प्रदान करना चाहते हैं। एक चीज जो मुझे लगता है कि हमें यहां करना चाहिए वह है एक विशेष मामला जोड़ना ताकि _pip_ के pip को अपग्रेड करना _pip-cli_ के pip को संक्रमण के दौरान अधिलेखित न करे लेकिन इसके विपरीत काम करता है।

आदर्श रूप से, हमारे पास _pip-cli_ का उपयोग करने के लिए किसी प्रकार की "बीटा" अवधि होगी जहां हम उपयोगकर्ताओं को _pip-cli_ का उपयोग करके परीक्षण करने के लिए कह सकते हैं। इससे पहले कि हम _pip_ में pip को हटा दें, इससे पहले की समस्याओं को दूर करने में मदद मिलेगी।

1. रिलीज नंबर
   
   
   
   • _pip_ के pip को हटा दें।
   
   
   • _pip-cli_ को _virtualenv_ में जोड़ें; यह सुनिश्चित करना कि यह _pip_ के बाद स्थापित हो जाए।
   
   
   • उपयोगकर्ताओं को _pip-cli_ पर स्विच करने का सुझाव दें।
   
   
2. रिलीज एन+2
   
   
   
   • _pip_ से pip निकालें।
   
   

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

अब, मुझे यकीन नहीं है कि हमें विवेक-जांच/डिबगिंग जानकारी के कुछ प्रकार को शामिल करना चाहिए या नहीं?

• _pip_ के pip ? रिलीज एन + 1 में?
• _pip-cli_'s pip ; रिलीज एन के लिए दौड़ में?

@ pypa/pip-committers आइए pipX और pipX.Y को pip 18.1 में हटा दें?

क्या हमारी योजना केवल लोगों को python -m pip का उपयोग करने के लिए कहने की है?

हां। हमारे पास यही होता।

यह उससे थोड़ा अधिक पेचीदा है, क्योंकि "पायथन" का उल्लेख नहीं हो सकता है
सही बात।

इसका मतलब है कि किसी भी बहिष्करण चेतावनी के आधार पर कुछ अनुमानों की आवश्यकता होगी
sys.executable, Shutil.who और चल रहे प्लेटफॉर्म यह तय करने के लिए कि क्या a
उपयुक्त प्रतिस्थापन होगा।