Pip: डिफ़ॉल्ट के लिए --user

pypa इंस्टाल निर्देशों के लिए इसका क्या अर्थ है?

वर्तमान में रूट या एडमिनिस्ट्रेटर एक्सेस का उल्लेख फुटनोट में है, इसलिए निर्देश मूल रूप से वही रहेंगे (यह मानते हुए कि get-pip स्वचालित रूप से --user पर भी डिफॉल्ट हो जाएगा)। परिवर्तन यह समझाने के लिए होगा कि वे ऐसे इंस्टॉल के साथ समाप्त हो जाएंगे जो केवल उनके वर्तमान उपयोगकर्ता पर लागू होते हैं।

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

लंबे समय तक मुझे पूरा यकीन है कि वे इसे सक्षम बनाए रखेंगे, वे बस यह पता लगा रहे हैं कि इसे कैसे किया जाए।

हालांकि इस मुद्दे के बारे में वर्णित किया गया है कि जहां पाइप को डिफ़ॉल्ट रूप से पैकेजों का प्रबंधन करना चाहिए, लगभग अधिक महत्वपूर्ण (मेरे लिए कम से कम) यह है कि यह अप्रत्यक्ष रूप से है जहां get-pip डिफ़ॉल्ट रूप से पाइप रखेगा।

यह altinstall'd Pythons के साथ कैसे इंटरैक्ट करता है?
विशेष रूप से जैसे कि https://github.com/yyuu/pyenv . जैसे टूल के साथ इंस्टॉल किए गए हैं

उपयोगकर्ता योजना .local/lib/pythonX.Y/site-packages है, इसलिए यदि आप एक ही प्रमुख/मामूली संस्करण के साथ एकाधिक पायथन प्रबंधित कर रहे हैं, तो मुझे लगता है कि आप एक गड़बड़ के साथ समाप्त हो सकते हैं।

इस तरह के उपकरणों के लिए, जो वास्तविक अजगर का प्रबंधन करते हैं, पाइप को वैश्विक मोड में पिन करना उन लोगों के लिए समझ में आता है।

रेडहैट/फेडोरा बग ट्रैकर पर एक प्रासंगिक मुद्दा https://bugzilla.redhat.com/show_bug.cgi?id=662034#c10

ऐसा लगता है कि Fedora/RedHat PATH=$PATH:$HOME/.local/bin:$HOME/bin पहले से ही उनके /etc/skel/.bash_profile में है। यह --user के साथ स्थापित सामान को अभी भी डिफ़ॉल्ट रूप से दिखाएगा, कम से कम बैश उपयोगकर्ताओं (डिफ़ॉल्ट शेल) के लिए। हो सकता है कि अन्य डिस्ट्रो के पास पहले से ही यह हो?

विंडोज़ के बारे में विशेष रूप से अलग कुछ भी नहीं है जिसे मैं जानता हूं। लेकिन हमें केवल लोगों के पाथ पर मानक पायथन निर्देशिका मिली है, मुझे उम्मीद नहीं है कि प्रति-उपयोगकर्ता स्क्रिप्ट निर्देशिका प्राप्त करना विशेष रूप से आसान होगा - और तकनीकी कठिनाइयां भी हो सकती हैं, मुझे यकीन नहीं है उपयोगकर्ता-स्तरीय पर्यावरण चर जैसे %LOCALAPPDATA% को सिस्टम-स्तर %PATH% $ में डालने से भी काम होता है :-(

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

इसके अलावा, मेरी विंडोज़ टोपी के साथ, मुझे यह कहना होगा कि यूनिक्स उपयोगकर्ताओं के लिए इसे कठिन बनाना जिन्होंने अभी तक काम नहीं किया है, सूडो का लापरवाह उपयोग बेवकूफ चीजें करना बुरा है, वास्तव में यह एक औचित्य नहीं है .. .

मुझे लगता है कि यह केवल सिस्टम पायथन से पाइप चलाते समय लागू होगा।

वैसे विंडोज़ पर अलग बात यह है कि वहां कोई सिस्टम नहीं है जो पाइथन प्रदान करता है जैसे कि * निक्स पर है जो सिस्टम प्रदान किए गए पायथन पैकेज के साथ आता है :)

मैं इसे विशेष रूप से जल्दी नहीं करना चाहता। मैं सिर्फ चर्चा शुरू करना चाहता था।

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

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

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

जैसा कि पॉल नोट करता है, विंडोज़ पर पाथ में _user_ स्क्रिप्ट निर्देशिका अभी तक शामिल नहीं है (केवल वैश्विक एक), इसलिए यह निश्चित रूप से ध्यान में रखने योग्य है।

हालाँकि मुझे POSIX की ओर कोई बड़ी बाधा नहीं दिख रही है। यह यूएक्स विचार कैसा लगता है: व्हील आधारित इंस्टॉलेशन के लिए, इंस्टॉलेशन लक्ष्य निर्देशिका पर अनुमतियों की जांच करें, और यदि उपयोगकर्ता के पास लिखने की अनुमति नहीं है, तो यह पूछने के लिए एक संकेत दें कि क्या वे इसके बजाय --user इंस्टॉल करना चाहते हैं? एक नया "--global" या "--system" ध्वज "नहीं" उत्तर के लिए बाध्य करेगा।

और फिर भविष्य में किसी बिंदु पर, हम प्रॉम्प्ट को छोड़ सकते हैं और बस मान सकते हैं --user अगर वैश्विक स्थापना के लिए अनुमतियां सही नहीं थीं।

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

अनिवार्य रूप से यह हमारे विफलता मोड को बहुत बेहतर बनाता है।

यूनिक्स उपयोगकर्ताओं के लिए इसे कठिन बना रहा है जिन्होंने अभी तक सूडो के लापरवाह उपयोग पर काम नहीं किया है
बेवकूफी भरी बातें करना बुरा है, क्या यह इतना अच्छा औचित्य नहीं है..

sudo और सुरक्षा वास्तव में एक माध्यमिक मुद्दा आईएमओ है।
यह मुख्य रूप से सिस्टम पायथन में ओएस पैकेजिंग और पाइप के बीच संघर्ष को रोकने के बारे में है।
वर्तमान में, linux उपयोगकर्ताओं को अक्सर एक असंभव स्थिति में रखा जाता है।

1. ओएस मैंडेट: 'ओएस पीकेजी एमजीआर का प्रयोग करें; अपने सिस्टम को roque pip-इंस्टॉल पैकेज ( get-pip 'd pip सहित)' से संक्रमित न करें।
2. वास्तविकता: "OS पैकेज (पाइप सहित) बहुत पुराने हैं, और मैं डिस्ट्रो के प्रायोगिक रिलीज़ में अपग्रेड नहीं कर सकता, बस कुछ पैकेज के अपग्रेड प्राप्त करने के लिए। मैं दुष्ट जा रहा हूँ ...."

एक और बेबी स्टेप दस्तावेज़ के लिए है (यह मानते हुए कि हम इसका परीक्षण करते हैं) कि आप get-pip.py --user कर सकते हैं, और PUG में --user virtualenv (और wheel ) की स्थापना के लिए एक संभावना के रूप में है। twine भी, यदि वर्चुअलएन्व में नहीं है)

FWIW, डिस्ट्रो वेंडर भी यथास्थिति को एक समस्या मानते हैं और कोर OS घटकों को प्रभावित किए बिना चयनात्मक उन्नयन करने के लिए उपकरणों को बेहतर बनाने के विभिन्न तरीकों पर विचार कर रहे हैं। हालांकि, यह अभी भी अपस्ट्रीम की ओर से निपटने के लायक है, क्योंकि वे प्रयास परिपक्वता के विभिन्न चरणों में हैं और हम अंतिम उपयोगकर्ताओं के लिए एक सुसंगत क्रॉस-प्लेटफ़ॉर्म समाधान चाहते हैं।

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

ध्यान दें कि विंडोज़ पर pip _is_ bad चलाते समय UAC को ट्रिगर करना, क्योंकि इसका वास्तव में मतलब यह है कि एक उन्नत कंसोल विंडो को छोड़कर pip नहीं चलेगा। इसका मतलब यह नहीं है कि पीआईपी उपयोगकर्ताओं को एक अच्छा संकेत मिलता है जिसे वे "ओके" कह सकते हैं, दुर्भाग्य से, केवल जीयूआई ऐप्स कैसे काम करते हैं ...

@pfmoore आपको क्या लगता है कि विंडोज़ का उपयोगकर्ता अनुभव कैसा होना चाहिए जब आप pip install कुछ और आपको निर्देशिका में लिखने की अनुमति नहीं है?

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

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

प्रस्ताव वैश्विक इंस्टॉल को उपयोगकर्ता इंस्टॉल के साथ प्रतिस्थापित नहीं कर रहा है
यह एक अनुमति त्रुटि को --user install . से बदल रहा है

ठीक है, लेकिन याद रखें कि अनुमतियाँ जाँच विचार (#1048) सबसे आसान काम नहीं होगा

व्हील केस में यह बहुत आसान होगा, और हम 99.9% केस को sdists से कवर कर सकते हैं, यह केवल setup.py में एक समस्या होनी चाहिए जो वास्तव में फंकी चीजें करती है।

आपको क्या लगता है कि विंडोज का उपयोगकर्ता अनुभव कैसा होना चाहिए जब आप कुछ स्थापित करते हैं और आपको निर्देशिका में लिखने की अनुमति नहीं होती है?

खैर, साइट-पैकेज निर्देशिका में लिखने में सक्षम होना विंडोज़ पर इतना दुर्लभ है कि मुझे यकीन नहीं है कि प्रश्न अभ्यास में कितना प्रासंगिक है। लेकिन अगर ऐसा हुआ, तो मैं कहूंगा कि "सिस्टम साइट-पैकेज लिखने योग्य नहीं है - क्या आपका मतलब --user का उपयोग करना है?" समझदार दृष्टिकोण होगा।

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

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

पॉल का सुझाव मोटे तौर पर मेरे दिमाग में था, लेकिन एक त्रुटि संदेश के साथ बाहर निकलने के बजाय हां/नहीं संकेत के साथ। उन दो दृष्टिकोणों के पक्ष और विपक्ष हैं (ज्यादातर किसी अन्य स्क्रिप्ट से लागू होने पर वे कैसे विफल होते हैं) से संबंधित हैं।

क्या पाइथन में sys.localprefix जैसे कुछ जोड़ना संभव होगा (मैं यहां पाइथन-देव देखता हूं)?
Sys.localprefix sys.prefix के लिए डिफ़ॉल्ट होगा। डिस्ट्रोस इसे उसी तरह परिभाषित कर सकते हैं जैसे वे उपसर्ग को परिभाषित करते हैं (जैसे उपसर्ग = '/ usr', स्थानीय उपसर्ग = '/ usr/स्थानीय')। Pip और easy_install sys.localprefix को एक स्थान के रूप में स्थापित करने के लिए यदि sudo के रूप में उपयोग किया जाता है, यदि उनके पास पर्याप्त अधिकार नहीं हैं तो --user पर वापस आते हैं।

हमने फेडोरा 17 में "जेम इंस्टाल" के साथ ऐसा कुछ किया है और रूबी डेवेल्स आम तौर पर इसके बारे में बहुत संतुष्ट थे, इसलिए मैंने सोचा कि मैं साझा करूंगा:

• "मणि इंस्टाल फू" "फू" को ~/somedir में इंस्टाल करता है अगर यूआईडी != 0
• "मणि स्थापित फू" "फू" को /usr/स्थानीय/somedir में स्थापित करता है यदि uid == 0
• "यम इंस्टाल रूबीगेम-फू" आरपीएम-पैकेज्ड "फू" को /usr/somedir में इंस्टाल करता है

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

@bkabrda जब तक आप $PATH में स्क्रिप्ट जोड़ने के बारे में चिंतित नहीं हैं, तब तक यह एक आसान विकल्प है। आपने वहां क्या किया है?

@Ivoz जैसा कि @dstufft द्वारा नोट किया गया है, फेडोरा के पास पहले से ही $HOME/.local/bin PATH पर है, इसलिए सब कुछ बॉक्स से बाहर काम किया (स्क्रिप्ट की बात)।

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

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

विंडोज़ में भी अजीबता है कि क्या पाइथन डिफ़ॉल्ट स्थान (अनियंत्रित) या प्रोग्राम फाइलों (परिवर्तन करने के लिए आवश्यक यूएसी विशेषाधिकार वृद्धि) में स्थापित है या नहीं।

@rkuska द्वारा सुझाया गया "लोकलप्रिफ़िक्स" विचार मुझे अच्छा, सरल और आसान लगता है। इसके अलावा, मुझे वास्तव में दृष्टिकोण पसंद है @bkabrda सुझाव देता है, विशेष रूप से आर्क जैसे डिस्ट्रोस के लिए जो कि अजगर 3.x को डिफ़ॉल्ट अजगर बनाते हैं।

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

@lvoz
आर्क के लिए हमने $HOME से PATH में कोई पथ नहीं जोड़ा, लेकिन मुझे अभी भी यह ठीक लगता है। रूबी के लिए हमारे पास पहले से ही विकी प्रविष्टि है जो उपयोगकर्ता को इसे जोड़ने के लिए कहती है।

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

केवल FYI करें, हमारे पास पहले से ही फेडोरा के Copr बिल्ड सिस्टम में Python 3.4 RPM बिल्ड काम कर रहा है (परीक्षण, यदि आप कुछ भी तोड़ना नहीं चाहते हैं तो उन्हें स्थापित करने की सलाह नहीं दी जाती है)। यदि आप इस बारे में अधिक जानना चाहते हैं कि हम इस तक कैसे पहुंचते हैं, तो कोड आदि पर एक नज़र डालें, डेबियन-पायथन एमएल पर बैरी वारसॉ [2] के साथ मेरी चर्चा देखें।
(हमारे पैच को अभी भी कुछ प्यार की जरूरत है इससे पहले कि हम उन्हें अपस्ट्रीम का प्रस्ताव दें, लेकिन डाउनस्ट्रीम एटीएम के लिए सब कुछ ठीक काम करता है)

[1] http://copr-fe.cloud.fedoraproject.org/coprs/bkabrda/python-3.4/
[2] https://lists.debian.org/debian-python/2014/03/msg00046.html

क्षमा करें, लेकिन AFAIK आर्क ने कभी भी पहिया का समर्थन नहीं किया, और न ही हम पैकेज मैनेजर को सुनिश्चित करना चाहते हैं (यदि मैं इस दृष्टिकोण को गलत समझता हूं, तो मुझे सुधारें)।

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

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

@felixonmars क्या इसका मतलब आर्क वेनव पर उसी तरह टूटा हुआ है जैसा कि डेबियन पर है?

ठीक है, स्पष्टीकरण के लिए धन्यवाद, मुझे लगता है कि मुझे यह विचार मिला। मैं देखूंगा कि मैं क्या कर सकता हूं और इसके लिए डेबियन-पायथन पर अनुवर्ती कार्रवाई करूंगा।

@dstufft हां, सिस्टम संस्करण के बजाय बंडल संस्करण स्थापित हो गया है।

@bkabrda ताकि समस्या हल हो जाए यदि आप सिस्टम पायथन के साथ पाइप का आह्वान कर रहे हैं, तो हमें उस मामले में वर्चुअलएन्व/वेनव विशेष केस करना होगा (जो दुनिया का अंत नहीं है)। लेकिन इसका मतलब यह भी है कि हम मान रहे हैं कि सभी पायथन सिस्टम पायथन हैं, यहां तक ​​​​कि उपयोगकर्ता द्वारा अपने होमडिर में स्थापित किए गए हैं जैसे कि https://github.com/yyuu/pyenv (जिस तरह से मैं वास्तव में पायथन चलाता हूं)। तो मुझे यकीन नहीं है, इसलिए मैंने अनुमति जांच के बारे में सोचा।

ठीक वैसा ही जैसा @dstufft ने कहा, गैर-रूट अजगरों को हथकंडा करने के लिए pyenv जैसे उपकरण का उपयोग करने में, यह root के लिए वैश्विक इंस्टॉल करने की कुंजी होने के लिए बहुत अजीब होगा (जहां "वैश्विक" != "सिस्टम")

हमने फेडोरा 17 में "जेम इंस्टाल" के साथ ऐसा कुछ किया है

आपका मतलब है कि फेडोरा 17 के लिए मणि की आरपीएम यह एक डिस्ट्रो हैक के रूप में है ?, या मणि के पास यह तर्क है?

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

आह @felixonmars मैंने अभी देखा https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/python , अगर आप केवल --without-ensurepip पर कॉल कर रहे हैं तो यह ठीक है . यह वेनव मॉड्यूल के लिए सुनिश्चितपिप मॉड्यूल को बरकरार रखता है। पैच उबंटू (डेबियन?) वर्तमान में मौजूद है, वास्तव में rm -rf को सुनिश्चितपिप पैकेज पर ही कॉल करता है, जिससे यह एक वेनव के भीतर कॉल करने के लिए अनुपलब्ध हो जाता है।

मुझे लगता है कि दो साल पहले निक द्वारा उपयोगकर्ता इंस्टॉल में डिफॉल्ट करने का प्रस्ताव दिया गया था, या शायद किसी और ने पहले, लेकिन धागा कई दिशाओं में चला गया और फलदायी नहीं था। मुख्य बाधा पिछड़ी संगत IIRC थी, लेकिन इन दिनों sysadmins और pip उपयोगकर्ता बेहतर या बदतर के लिए virtualenv/pip/setuptools अपडेट से सावधान रहने के लिए अधिक उपयोग किए जा सकते हैं। मुझे याद नहीं कि वह चर्चा डिस्टुटिल्स-सिग या पिपा-देव पर हुई थी।

यह कैटलॉग-सिग था: https://mail.python.org/pipermail/catalog-sig/2013-February/004773.html

@dstufft ओह, मैं देखता हूं ... लेकिन मुझे अभी भी एक बंडल (शायद पुराना) संस्करण स्थापित करना गलत लगता है, जबकि सिस्टम-वार पैकेज स्थापित हैं :)

@felixonmars अच्छी तरह से समस्या यह है कि आप वर्चुअलएन्व afaik में एक सिस्टम पैकेज स्थापित नहीं कर सकते :) (और यहां तक ​​​​कि यदि आप सिस्टम पैकेज में वर्चुअलएन्व के अंदर जो चाहते हैं उसके साथ अलग-अलग चिंताएं हो सकती हैं)

@dstufft यही वह जगह है जहां स्लेवेक का रीव्हील किक करता है, लेकिन यह थोड़ा सा विषय है :)

हाँ, https://lists.fedoraproject.org/pipermail/python-devel/2014-March/000583.html के अंतिम बिट की जाँच करें :(

@dstufft धन्यवाद!

सुनिश्चित नहीं है कि मुझे वहां चर्चा जारी रखनी चाहिए, क्योंकि यह कोई समस्या नहीं होनी चाहिए क्योंकि हमने आर्क में पाइप को अनबंडल नहीं किया है, और रीव्हील को प्रयोग करने योग्य पहिया उत्पन्न करना चाहिए :)

@dstufft आप सही कह रहे हैं कि हमें शायद वर्चुअलएन्व और संभवतः यहां तक ​​​​कि pyenv, जो बदसूरत लगता है, विशेष करने की आवश्यकता होगी। मुझे यह स्वीकार करना होगा कि मैं pyenv से परिचित नहीं हूं, इसलिए मैं अभी इसके लिए कोई "उचित" समाधान नहीं सोच सकता। मैं इसे करीब से देखने और कुछ सोचने की कोशिश करूंगा।

फेडोरा पर "मणि इंस्टॉल" के लिए @qwcode , यह डाउनस्ट्रीम पैच है। टीबीएच मैंने लंबे समय तक फेडोरा के रूबीगेम्स को नहीं छुआ, लेकिन पिछली बार जब मैंने जाँच की, तो यह केवल डाउनस्ट्रीम था।

मैंने इस मुद्दे का लिंक अजगर में संबंधित बग से पोस्ट किया है [1]। मैं इस चर्चा को पायथन कोर में स्थानांतरित करना चाहता हूं, न केवल pip बल्कि easy_install और python setup.py install के स्थानीय इंस्टॉलेशन के लिए एक विन्यास योग्य स्थान रखने के लिए, उसके बाद पाइप का उपयोग कर सकता है ( उदाहरण के लिए) sys.localprefix dir यदि uid==0 और उपयोगकर्ता dir में स्थापित करें यदि uid!=0 जैसा कि @bkabrda ने उल्लेख किया है।

कुछ समय के लिए मैं डिफ़ॉल्ट रूप से उपयोगकर्ता डीआईआर में पीआईपी स्थापित करने के साथ ठीक हूं।

[1] http://bugs.python.org/issue1298835

जैसा कि निक ने बताया कि मैंने चर्चा को अंक 1298835 से पीपा-देव [1] में स्थानांतरित कर दिया।
[1] https://groups.google.com/forum/#!topic/pypa -dev/r6qsAmJl9t0

डिफ़ॉल्ट के लिए --user

अच्छा विचार!

pip install foo एक त्रुटि फेंक देगा क्योंकि इसमें फ़ाइल अनुमतियां नहीं हैं। यह लोगों को इसके बजाय sudo pip install foo चलाने का कारण बनता है जो विश्व स्तर पर सिस्टम पायथन में स्थापित होता है

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

1. उनके व्यवस्थापक को ईमेल करें और उन्हें पैकेज स्थापित करने के लिए कहें। यह सभी के लिए धीमा और थकाऊ है।
2. पैकेज के बिना छोड़ दो और करो।

केवल अगर वे विशेष रूप से अनुभवी या अच्छी तरह से वाकिफ हैं, तो वे pip install --user प्रयास करेंगे।

यदि हम '--उपयोगकर्ता के लिए डिफ़ॉल्ट' के विरुद्ध निर्णय लेते हैं, तो हमें कम विघटनकारी विकल्पों पर विचार करना चाहिए:

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

मैं वास्तव में कुछ समय से अपने सभी इंस्टॉलेशन में --user का उपयोग कर रहा हूं, लेकिन आम तौर पर लोगों को इस विकल्प के बारे में पता नहीं होता है। मैं मानता हूं कि हर बार जब आप विकल्प भूल जाते हैं तो अनुमति त्रुटि को देखना कष्टप्रद होता है। मैंने देखा है कि उपयोगकर्ता इंस्टॉलेशन कोंडा के साथ संगत नहीं हैं, हालांकि (conda/conda#448)।

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

मुझे इंस्टॉलेशन के लिए "फ़ॉलबैक टू --यूज़र ऑन परमिशन एरर" विकल्प सबसे अच्छा लगता है, अनइंस्टॉल पर "डिफॉल्ट टू --यूसर और फॉलबैक टू सिस्टम" और शायद --system या --system-only विकल्प जोड़ें वापसी को रोकने के लिए। व्यवस्थापक अनुमतियों के साथ जानबूझकर पाइप चलाने वाले उपयोगकर्ताओं को अपेक्षित रूप से एक सिस्टम इंस्टॉल मिलेगा, और वर्तमान में बिना अनुमति वाले उपयोगकर्ताओं को एक त्रुटि मिलेगी, इसलिए मुझे विश्वास नहीं है कि यहां कोई बैक-कंपैट समस्या है।

मेरा उद्देश्य एक अनजान उपयोगकर्ता के लिए त्रुटियों के बिना pip install spam; python -c "import spam" करने में सक्षम होना है (हालांकि संभवतः --user के साथ पुन: प्रयास करते समय चेतावनी)।

मैं इसके बारे में हाल ही में सोच रहा हूं, खासकर जब से #2403 और #2401 हाल ही में खोले गए थे, जिसने मुझे sudo pip install के उपयोग के बारे में सोचने पर मजबूर कर दिया और यह कैसे अक्सर केवल अनुमति समस्याओं के बाहर सिस्टम को तोड़ सकता है।

यह अंत करने के लिए मुझे आश्चर्य है कि बेहतर अंत लक्ष्य सिर्फ यह नहीं है कि --user डिफ़ॉल्ट है, कोई जादुई अनुमति जांच नहीं है, और --global , --system जैसे एक नया ध्वज जोड़ें, या --no-user जो पिछले व्यवहार को पुनर्स्थापित करेगा। लोगों को यह समझाना आसान है क्योंकि इसका व्यवहार समान होगा चाहे चीजें कैसे/कहाँ स्थापित हों।

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

एक और महत्वपूर्ण सवाल यह है कि अगर हमें पता चलता है कि हम जिस पायथन में स्थापित कर रहे हैं, उसमें उपयोगकर्ता साइट सक्षम नहीं हैं, तो हमें क्या करना चाहिए। इस मामले में मैं केवल यह कहूंगा कि --user एक त्रुटि है और उन पायथन के लिए हम केवल --global पर डिफ़ॉल्ट रूप से वापस आ जाएंगे। यह वर्चुअलएन्व/वेनव को कवर करेगा जो मैं स्वचालित रूप से मानता हूं, और अगर कोई पूरी तरह से संकलित पायथन का उपयोग करके "भारी" वजन पृथक वातावरण चाहता है तो वे केवल site.py पैच कर सकते हैं ताकि वे ENABLE_USER_SITE से False फ़ाइल के शीर्ष पर।

+1, और मैं --system के लिए वोट करूंगा।

मैं नोट करूँगा, और मुझे यकीन है कि आप इसे पसंद करेंगे, उबंटू डिफ़ॉल्ट बदल गया है:

https://launchpad.net/ubuntu/+source/python-pip/1.5.6-4ubuntu1

09 फरवरी, 2015 को शाम 04:41 बजे, डोनाल्ड स्टफ ने लिखा:

यह अंत करने के लिए मुझे आश्चर्य है कि बेहतर अंत लक्ष्य सिर्फ यह नहीं है कि --user है
डिफ़ॉल्ट, कोई जादुई अनुमति जांच नहीं करता है, और --global जैसा एक नया ध्वज जोड़ें,
--system , या --no-user जो पिछले व्यवहार को पुनर्स्थापित करेगा। इस
लोगों को समझाना आसान है क्योंकि इसका व्यवहार एक जैसा होगा, इससे कोई फर्क नहीं पड़ता
चीजें कैसे/कहां स्थापित की जाती हैं।

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

• विंडोज़ पर पायथन
• पाइनेव ने पायथन स्थापित किया
• कोंडा ने पायथन स्थापित किया
• निक्स स्थापित पायथन
• कस्टम संकलित पायथन।

यह _only_ *nix सिस्टम पर लागू होता है जहां सिस्टम द्वारा Python को शिप किया जाता है। मुझे लगता है कि --global उस झंडे के लिए एक बेहतर नाम है।

और FML, डेबियन/उबंटू को लगातार यादृच्छिक पैच जोड़ने की आवश्यकता क्यों महसूस होती है जो अपेक्षित उपयोग के मामलों को तोड़ते हैं?

तो अगर उबंटू पैच वापस हो जाता है, तो इस पर समयरेखा क्या तय हो रही है? एक हफ्ता/महीना/3 महीने/6 महीने/साल...?

यह इस बात पर निर्भर करता है कि फिक्स्ड से आपका क्या मतलब है।

एक पल के लिए मान लें कि हम उस विचार का उपयोग कर रहे हैं जो मेरे पास 2 पोस्ट पहले था (जिसे अभी भी अन्य पीआईपी डेवलपर्स से साइन ऑफ की आवश्यकता है) हम संभवतः संक्रमण योजना प्राप्त कर सकते हैं जहां निम्नलिखित सत्य हैं:

• जब --user पास हो जाता है तो हम _always_ उपयोगकर्ता साइट पैकेज में इंस्टॉल करते हैं।
• जब --global (या जो कुछ भी) पास हो जाता है तो हम _always_ वैश्विक साइट पैकेज में स्थापित करते हैं।
• जब न तो पारित किया जाता है तो हम एक फ़ॉलबैक विधि लागू करते हैं जो:
  
  
  
  • पता लगाता है कि क्या हम एक आभासी वातावरण में हैं और यदि ऐसा है तो यह कार्य करता है जैसे कि --global पारित किया गया था।
  
  
  • पता लगाता है कि उपयोगकर्ता साइट-पैकेज अक्षम है या नहीं और यदि ऐसा है तो --global पारित किया गया था।
  
  
  • यह पता लगाता है कि प्रभावी उपयोगकर्ता के पास sys.path के लिए लिखने की अनुमति नहीं है, और यदि वे ऐसा कार्य नहीं करते हैं जैसे कि --user पारित किया गया था।
  
  
  • अंत में, यदि अन्य सभी पता लगाने के तरीके विफल हो जाते हैं, तो कार्य करें जैसे कि --global पारित किया गया था और यह कहते हुए एक बहिष्करण चेतावनी प्रिंट करें कि भविष्य में किसी बिंदु पर इसका व्यवहार बदल जाएगा और यह इसके बजाय --user में स्थापित हो जाएगा।
  
  

यह किसी को अपने सिस्टम पायथन में sudo pip install foo करने से नहीं रोकेगा, हालांकि यह एक चेतावनी प्रिंट करेगा कि किसी बिंदु पर इसका मतलब --user होगा और उन्हें स्पष्ट रूप से --global का उपयोग शुरू करने के लिए कहेंगे

• जब --user पास हो जाता है तो हम _always_ उपयोगकर्ता साइट पैकेज में इंस्टॉल करते हैं।
• जब --global (या जो कुछ भी) पास हो जाता है तो हम _always_ वैश्विक साइट पैकेज में स्थापित करते हैं।
• जब कोई भी विकल्प पास नहीं होता है तो हम एक फ़ॉलबैक विधि लागू करते हैं जो:
  
  
  
  • पता लगाता है कि क्या हम एक आभासी वातावरण में हैं और यदि ऐसा है तो ऐसा कार्य करता है जैसे कि --global पारित किया गया था।
  
  
  • यह पता लगाता है कि उपयोगकर्ता साइट-पैकेज अक्षम है या नहीं और यदि ऐसा है तो यह कार्य करता है जैसे कि --global पारित किया गया था।
  
  
  • अंत में डिफ़ॉल्ट के रूप में --user का उपयोग करता है।
  
  

हालाँकि, पहले व्यवहार से दूसरे व्यवहार में जाने के लिए काफी लंबी समयावधि होने वाली है। यह वास्तव में एक बड़ा ब्रेकिंग परिवर्तन होने जा रहा है जो किसी भी सॉफ़्टवेयर (जैसे नमक, शेफ, कठपुतली) या परिनियोजन स्क्रिप्ट के लिए चीजों को तोड़ने वाला है (जैसे दुनिया भर में हजारों परियोजनाओं में पके हुए फैब्रिक स्क्रिप्ट से कस्टम एक) जो उम्मीद करता है कि sudo pip install <foo> वैश्विक पायथन में स्थापित होने जा रहा है। हमें लोगों को चेतावनी देखने के लिए एक लंबा समय देना होगा, और यदि उन्हें वास्तव में उस व्यवहार की आवश्यकता है तो एक स्पष्ट --global ध्वज को पारित करने के लिए उनके सॉफ़्टवेयर और स्क्रिप्ट को संशोधित करना होगा।

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

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

@dstufft : अगर आपको मेरी ज़रूरत है तो उबंटू बग पर बताए गए आपके प्रस्ताव को लागू करने के लिए मुझे हाथ देने में खुशी हो रही है। एक बार जब हम ट्रंक में उस व्यवहार को प्राप्त कर लेते हैं, तो मैं निश्चित रूप से वर्तमान ubuntu पैच को बैकपोर्ट और बदल दूंगा।

अगर आपको कोई मदद चाहिए तो मुझे पोस्ट करते रहें।

मैं @dstufft की योजना पर +1 हूं। मैं बताए गए कारणों के लिए, नाम के रूप में --global के लिए जाऊंगा। हम लंबे समय से बाड़ पर बैठे हैं, चलो इसके लिए चलते हैं।

@ncoghlan के सुझाव पर O'n और +1 कि Python 3.5 Windows पर PATH में उपयोगकर्ता साइट निर्देशिका जोड़ें। आइए इस संक्रमण के लिए किसी और रुकावट से बचें।

मैं @dstufft की योजना के लिए +1 और --global के लिए +1 भी हूं, हालांकि मैं अभी भी sudo pip install foo की आवश्यकता --global के बारे में सोच रहा हूं। क्या वास्तव में उपयोगकर्ता साइट पैकेज रखने के लिए रूट की कोई आवश्यकता है? क्या हम साइट पैकेज को डिफ़ॉल्ट रूप से बंद करने के लिए विशेष केस रूट कर सकते हैं? (जो sudo pip install foo को ठीक वैसे ही काम करेगा जैसा वह अभी करता है)

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

एक विचार जो मेरे साथ हुआ वह यह है कि उपयोगकर्ता साइट निर्देशिका पायथन के कई संस्करणों के साथ कैसे काम करेगी?

अगर मैं पायथन 2.7 और 3.4 (पायथन 3.4 मेरे डिफ़ॉल्ट पायथन के साथ) में pip install pytest --user करता हूं, तो कौन सा संस्करण py.test कमांड निष्पादित करेगा? मुझे संदेह है कि दो इंस्टॉलेशन एक-दूसरे को ओवरराइट कर देंगे, इसलिए यह "आखिरी एक जीत" स्थिति है, जो _not_ अच्छा है। साथ ही, अगर यह "पिछली जीत" है, और मैं 3.4 संस्करण के बाद 2.7 संस्करण स्थापित करता हूं, तो मैं इसे 3.4 को फिर से डिफ़ॉल्ट बनाने के लिए कैसे ठीक करूं?

और अनइंस्टॉल के बारे में क्या? निम्नलिखित परिदृश्य पर विचार करें (अनचाहे, क्योंकि अगर मैं अपने मुख्य लैपटॉप को तोड़ने का जोखिम नहीं उठाना चाहता तो मुझे एक क्लीन मशीन स्थापित करने की आवश्यकता होगी):

    C:\Apps\Python34\python.exe -m pip install pytest --user
    C:\Apps\Python27\python.exe -m pip install pytest --user
    C:\Apps\Python34\python.exe -m pip uninstall -y pytest

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

दूसरा, क्या अनइंस्टॉल विफल नहीं होगा क्योंकि py.test.exe का चेकसम RECORD फ़ाइल के मान से मेल नहीं खाएगा? अगर यह विफल हो जाता है, तो मैं अनइंस्टॉल कैसे करूं? यदि यह विफल नहीं होता है, तो क्या यह मेरी पायथन 2.7 पाइटेस्ट की प्रतिलिपि (exe को हटाकर) तोड़ देगा?

और अंत में (अभी के लिए!) क्या उपयोगकर्ता स्क्रिप्ट निर्देशिका PATH में सिस्टम स्क्रिप्ट निर्देशिका से पहले या बाद में जाएगी? आईएमओ, इसे बाद में जाना चाहिए, अन्यथा एक उपयोगकर्ता ने पायथन में एक पैकेज की स्थापना की जिसे _not_ उपयोगकर्ता द्वारा "डिफ़ॉल्ट पायथन" होने का अनुरोध किया गया था, "डिफ़ॉल्ट" पायथन के सिस्टम साइट-पैकेज में स्थापित उसी पैकेज को ओवरराइड कर सकता है।

हम्म, हो सकता है कि कुछ खुले प्रश्न हों जिन्हें हमें यह परिवर्तन करने से पहले हल करने की आवश्यकता हो...

मुझे उम्मीद है कि साझा विंडोज उपयोगकर्ता स्क्रिप्ट निर्देशिका में नाम संघर्ष उसी तरह से संभाला जाएगा जैसे वे POSIX सिस्टम पर अपनी साझा बिन निर्देशिकाओं के साथ संभाले जाते हैं: पायथन 3 स्थापित पैकेजों के लिए अयोग्य स्क्रिप्ट नाम स्थापित नहीं करेगा, इसलिए अयोग्य नाम पायथन 2 संस्करण को संदर्भित करेगा।

सिस्टम इंस्टॉल या प्रति-उपयोगकर्ता इंस्टॉल डिफ़ॉल्ट रूप से प्राथमिकता लेता है या नहीं: सिस्टम एक के बाद उपयोगकर्ता स्क्रिप्ट निर्देशिका डालें।

"पायथन 3 स्थापित पैकेजों के लिए अयोग्य स्क्रिप्ट नाम स्थापित नहीं करेगा" - संभवतः आपका मतलब है कि पीआईपी और सेटपूल (पायथन 3 के तहत) यहां नहीं होगा? तो क्या यह उन उपकरणों में बदलाव है?

ओह, और ब्लेह। मेरी मांसपेशियों की स्मृति मेरे डिफ़ॉल्ट पायथन (3.4) में स्थापित करने के लिए "पाइप इंस्टॉल फू" टाइप करने के लिए 100% प्रशिक्षित है। यह फिर से प्रशिक्षित करने के लिए नरक होने जा रहा है।

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

शायद सबसे सरल उत्तर यह है कि उपयोगकर्ता स्क्रिप्ट निर्देशिका को संस्करणित किया जाना चाहिए, ठीक उसी तरह जैसे उपयोगकर्ता साइट पैकेज निर्देशिका है?

ओह, और क्या यह बहस यहाँ के बजाय अजगर-देव पर होनी चाहिए, क्योंकि यह आमतौर पर उपयोगकर्ता साइट निर्देशिका के बारे में है?

पाइथन-देव पर विंडोज़ प्रति-उपयोगकर्ता स्क्रिप्ट निर्देशिका के लिए पीईपी 370 डिज़ाइन चर्चा को दोबारा खोलना निश्चित रूप से उचित होगा। यह अजीब है कि विंडोज़ पर वैश्विक स्क्रिप्ट इंस्टॉलेशन को पायथन संस्करण द्वारा स्कोप किया गया है, लेकिन प्रति-उपयोगकर्ता स्क्रिप्ट इंस्टॉलेशन नहीं हैं।

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

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

फिर से समझा -m , लेकिन पिछली बार जब चीजों को दस्तावेज करने के संदर्भ में लाया गया था, तो मजबूत प्राथमिकता यह थी कि हमें चीजों को स्थापित करने के लिए pip install foo के रूप में व्यवहार करना चाहिए ( -m के साथ)

पाइप मैनुअल में _mention_ विकल्प भी नहीं हैं (विंडोज़ पर पाइप को अपग्रेड करने के लिए -m का उपयोग करने के एक मामले को छोड़कर)।

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

फरवरी 09, 2015, 07:58 अपराह्न पर, ncoghlan ने लिखा:

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

मुझे यह पसंद हे। जिन चीजों से हम जूझ रहे हैं उनमें से एक यह है कि कैसे हल किया जाए
--user डिफ़ॉल्ट में माइग्रेट करने के लिए अपस्ट्रीम का अधिक रूढ़िवादी दृष्टिकोण, के साथ
पाइप सिस्टम को सुरक्षित और अन्य के अनुरूप बनाने के डिस्ट्रो प्रतिस्पर्धी लक्ष्य
उपकरण। उदाहरण के लिए

https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1419695
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725848

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

मुझे नहीं लगता कि डेबंटू वर्तमान में एक साइट-व्यापी pip.conf फ़ाइल स्थापित करता है (मेरे पास होगा
डबल चेक करने के लिए)।

https://pip.pypa.io/hi/latest/user_guide.html#configuration

एक जटिलता: हम पायथन 2 और पायथन 3 के लिए अलग-अलग पाइप स्क्रिप्ट स्थापित करते हैं,
इसलिए मुझे लगता है कि हमें विभिन्न संस्करणों के लिए अलग-अलग कॉन्फ़िगरेशन फ़ाइलों की आवश्यकता होगी
पायथन, जैसे /etc/{xdg/pip/}/pip{2,3}.conf या कुछ ऐसे।

10 फरवरी 2015 को सुबह 01:24 बजे पॉल मूर ने लिखा:

एक विचार जो मेरे साथ हुआ वह यह है कि उपयोगकर्ता साइट निर्देशिका कैसे काम करेगी
पायथन के कई संस्करण स्थापित?

डेबियन/उबंटू (शायद सभी * निक्स?) पर हमारी कोई टक्कर नहीं है क्योंकि
पुस्तकालय ~/.local/lib/pythonX.Y/site-packages . में स्थापित हो जाते हैं

हम _do_ हालांकि ~/.local/bin पर टकराव प्राप्त करते हैं। a . के साथ एक पैकेज स्थापित करना
pip install --user foo और pip3 install --user foo का उपयोग कर स्क्रिप्ट 'फू'
अंत में ~/.local/bin/foo स्क्रिप्ट को बंद कर दें।

इस परिवर्तन का एक नकारात्मक पहलू यह है कि मुझे लगता है कि फेडोरा एकमात्र डाउनस्ट्रीम डिस्ट्रो है जो डिफ़ॉल्ट रूप से ~/.local/bin से $PATH जोड़ता है (और इसे /usr/bin और /usr/local/bin से पहले आना चाहिए) जैसे उपयोगकर्ता साइट पैकेज साइट-पैकेज से पहले आते हैं)। आदर्श रूप से डाउनस्ट्रीम अपने सिस्टम को संशोधित करने में सक्षम होंगे ताकि ~/.local/bin डिफ़ॉल्ट रूप से $PATH पर हो।

10 फरवरी 2015 को सुबह 07:24 बजे डोनाल्ड स्टफ ने लिखा:

इस बदलाव का एक नकारात्मक पहलू यह है कि मुझे लगता है कि फेडोरा एकमात्र डाउनस्ट्रीम है
डिस्ट्रो जो डिफ़ॉल्ट रूप से ~/.local/bin से $PATH जोड़ता है (और यह आना चाहिए
पहले /usr/bin और /usr/local/bin जैसे उपयोगकर्ता साइट पैकेज आता है
साइट-पैकेज से पहले)। आदर्श रूप से डाउनस्ट्रीम अपने को संशोधित करने में सक्षम होंगे
सिस्टम ताकि ~/.local/bin डिफ़ॉल्ट रूप से $PATH पर हो।

हां, लेकिन हम इसके बारे में अलग से फैसला कर सकते हैं। (या बल्कि, डाउनस्ट्रीम
डिस्ट्रोस ऐसा कर सकते हैं।)

(और यह उपयोगकर्ता की तरह ही /usr/bin और /usr/local/bin से पहले आना चाहिए
साइट पैकेज साइट-पैकेज से पहले आते हैं)

हम्म, @ncoghlan ने इसके विपरीत कहा, कि (विंडोज़ पर, उस विशेष में
संदर्भ) उपयोगकर्ता स्क्रिप्ट निर्देशिका सिस्टम एक के बाद _ होनी चाहिए। कौन कौन से
मैं तब तक सहमत हूं जब तक उपयोगकर्ता स्क्रिप्ट निर्देशिका अपरिवर्तित है। अगर यह है
संस्करण, मैं कम चिंतित हूँ। लेकिन यह शायद इस तथ्य को दर्शाता है कि
विंडोज यूजर्स को कभी भी अनवर्जन स्क्रिप्ट्स को क्लैश करने की जरूरत नहीं पड़ी
pip2/pip3 जैसे राक्षस, जिस तरह से यूनिक्स उपयोगकर्ताओं के पास है ;-)

ओह, और स्क्रिप्ट क्लॉबरिंग चीज़ एक अधिक सामान्य समस्या है जो वास्तव में --user से बिल्कुल संबंधित नहीं है। विंडोज़ --global इंस्टॉल को छोड़कर हर जगह एक ही समस्या मौजूद है। मुझे लगता है कि उस समस्या का समाधान एक माध्यमिक चिंता/समस्या है जिसे हमें इस मुद्दे पर अलग से हल करना चाहिए।

तो वर्तमान विचार:

• मुझे लगता है कि मेरे द्वारा पहले पोस्ट किए गए सामान्य विचार पर सहमति है, इसलिए मुझे लगता है कि हम कुछ इस तरह से आगे बढ़ना चाहेंगे।
• हम --global ध्वज का उपयोग करने जा रहे हैं।
• यदि हम --user में इंस्टॉल कर रहे हैं और ~/.local/bin $PATH पर नहीं है, तो हम शायद किसी प्रकार की चेतावनी चाहते हैं।
• हम किसी प्रकार का default-install विकल्प चाहते हैं जो अनिवार्य रूप से फ़ॉलबैक व्यवहार को अक्षम कर देगा और केवल --global या --user को हार्डकोड कर देगा।
• पाइप 6.0 के अनुसार हमारे पास /etc/ में स्थित मशीन विशिष्ट कॉन्फ़िगरेशन फ़ाइलें हैं, हालांकि ये पाइथन के संस्करण के लिए विशिष्ट नहीं हैं जो पाइप निष्पादित कर रहा है। मुझे लगता है कि यह एक अच्छी विशेषता है, हालांकि कुछ हद तक अलग भी है (और स्क्रिप्ट क्लॉबरिंग चीज़ को हल करने के साथ-साथ हाथ से भी जा सकता है)।

मुझे अभी भी एक प्रमुख खुला प्रश्न दिखाई दे रहा है: दीर्घावधि में हम क्या करना चाहते हैं जब कोई sudo pip install foo करता है या इसके बजाय, यदि किसी के पास site-packages निर्देशिका में लिखने की अनुमति है?

मैं जिन विकल्पों के बारे में सोच सकता हूं वे हैं:

1. --global में स्थापित करें। यह सबसे पिछड़ा संगत विकल्प है और संभावित रूप से यह दर्शाता है कि उपयोगकर्ता इसे टाइप करते समय क्या उम्मीद करते हैं। हालाँकि इसका नकारात्मक पक्ष यह है कि यह (चुपचाप) वैश्विक पायथन के साथ खिलवाड़ करेगा, जो कई प्रणालियों पर टूटे हुए सिस्टम का कारण बन सकता है।
2. में स्थापित करें --user , यह टूटे हुए सिस्टम से रक्षा करेगा (मुझे लगता है?) लेकिन मुझे नहीं लगता कि कोई भी रूट उपयोगकर्ता को /root/.local/ इंस्टाल करने की उम्मीद करेगा।
3. बस त्रुटि हुई और उपयोगकर्ता को मैन्युअल रूप से --user या --global का चयन करने की आवश्यकता है।
4. पहले दो विकल्पों में से एक चुनें, लेकिन एक स्विच प्रदान करें जो डिस्ट्रोस /etc/ में चालू कर सकता है जो तीसरे विकल्प को सक्षम करेगा।

चौथा विकल्प सबसे अच्छा हो सकता है लेकिन मुझे लगता है कि हमें पहले अन्य विकल्पों में से किसी एक को चुनने का प्रयास करना चाहिए यदि हम किसी प्रकार के समाधान पर आ सकते हैं जो सभी प्लेटफार्मों/परिदृश्यों पर समान रूप से काम करता है और उन सभी पर समझ में आता है जैसे मैं यदि संभव हो तो सुसंगत व्यवहार क्रॉस प्लेटफॉर्म रखना पसंद करेंगे।

मुझे लगता है कि तीसरा विकल्प खराब होने की संभावना है, क्योंकि "मेरे पास लिखने की अनुमति है" यह परिदृश्य होने जा रहा है कि विंडोज़ पर कोई भी पूर्व पायथन 3.5 पर है, या कोई भी जो कोंडा का उपयोग करता है, या कोई भी जो pyenv का उपयोग करता है। उन सभी मामलों में गलत काम करना गलत लगता है और यह बूट करने के लिए उपयोगकर्ता के अनुकूल नहीं है।

तो मुझे लगता है कि 1 और 2 के बीच यह वास्तव में नीचे आता है कि हमें लगता है कि यह लोगों के लिए कितना बुरा है (वैचारिक रूप से) sudo pip install --global foo । विंडोज़, कोंडा, पायनेव इत्यादि पर मुझे लगता है कि इसका उत्तर "हमें नहीं लगता कि यह एक बुरा अभ्यास है"। * निक्स पर मुझे लगता है कि शायद उत्तर "उपयोगकर्ताओं को वह करने की अनुमति दी जानी चाहिए जो वे अपने सिस्टम में चाहते हैं लेकिन हमें उन्हें" खराब "चीजों से दूर ले जाने के लिए रेल प्रदान करनी चाहिए"।

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

तो मेरा अद्यतन प्रस्ताव होगा:

• जब --user पास हो जाता है तो हम हमेशा उपयोगकर्ता साइट पैकेज में इंस्टॉल करते हैं।
• जब --global पारित हो जाता है तो हम हमेशा वैश्विक साइट पैकेज में स्थापित होते हैं।
• जब न तो पारित किया जाता है तो हम एक फ़ॉलबैक विधि लागू करते हैं जो:
  
  
  
  1. पता लगाता है कि क्या हम एक आभासी वातावरण में हैं और यदि ऐसा है तो ऐसा कार्य करता है जैसे कि --global पारित किया गया था।
  
  
  2. यह पता लगाता है कि उपयोगकर्ता साइट-पैकेज अक्षम है या नहीं और यदि ऐसा है तो यह कार्य करता है जैसे कि --global पारित किया गया था।
  
  
  3. default-install को देखता है और यदि वह मौजूद है तो उसके आधार पर --user या -global का उपयोग करता है।
  
  
  4. यह पता लगाता है कि प्रभावी उपयोगकर्ता के पास वैश्विक साइट पैकेजों के लिए लिखने की अनुमति नहीं है, और यदि वे कार्य नहीं करते हैं जैसे कि --user पारित किया गया था।
  
  
  5. अंत में, यदि अन्य सभी पता लगाने के तरीके विफल हो गए, तो कार्य करें जैसे कि --global पारित किया गया था।
  
  

इसका मतलब कोई मूल्यह्रास अवधि नहीं होगी और यह अपेक्षा है कि --user या --global की अनुपस्थिति में हम उस पायथन की क्षमताओं के आधार पर सर्वोत्तम अनुमान लगाने का प्रयास करेंगे जिसमें हम चल रहे हैं , प्रभावी उपयोगकर्ता, और कोई भी कॉन्फ़िगर की गई डिफ़ॉल्ट इंस्टॉल विधि।

(और यह उपयोगकर्ता की तरह ही /usr/bin और /usr/local/bin से पहले आना चाहिए
साइट पैकेज साइट-पैकेज से पहले आते हैं)

हम्म, @ncoghlan ने इसके विपरीत कहा, कि (विंडोज़ पर, उस विशेष में
संदर्भ) उपयोगकर्ता स्क्रिप्ट निर्देशिका सिस्टम एक के बाद _ होनी चाहिए। कौन कौन से
मैं तब तक सहमत हूं जब तक उपयोगकर्ता स्क्रिप्ट निर्देशिका अपरिवर्तित है। अगर यह है
संस्करण, मैं कम चिंतित हूँ। लेकिन यह शायद इस तथ्य को दर्शाता है कि
विंडोज यूजर्स को कभी भी अनवर्जन स्क्रिप्ट्स को क्लैश करने की जरूरत नहीं पड़ी
pip2/pip3 जैसे राक्षस, जिस तरह से यूनिक्स उपयोगकर्ताओं के पास है ;-)

मैं स्क्रिप्ट के नामों के टकराने के बारे में सोच भी नहीं रहा हूं। मुझे लगता है कि हमारे $PATH चर के लिए sys.path की तुलना में अलग तरीके से कार्य करना बिल्कुल गलत है। जहाँ तक मुझे पता है sys.path का क्रम है: stdlib > उपयोगकर्ता साइट संकुल > वैश्विक साइट संकुल। मुझे लगता है कि यह वास्तव में भ्रमित करने वाला होगा यदि some-script का आदेश वैश्विक बिन डीआईआर> उपयोगकर्ता बिन डीआईआर था जबकि python -m some-script उपयोगकर्ता साइट पैकेज> वैश्विक साइट पैकेज था।

यदि स्क्रिप्ट निर्देशिकाओं में कोई समस्या है (और संस्करणित बनाम असंक्रमित) तो मुझे लगता है कि हमें उस समस्या को ठीक करना चाहिए, लेकिन यह किस क्रम में होना चाहिए, इसके लिए यह बहुत प्रासंगिक नहीं है, क्योंकि मुझे लगता है कि sys.path से मेल खाने के अलावा कुछ भी नहीं है।

अच्छा बिंदु, हमें यह मान लेना चाहिए (और अनुशंसा करें) कि $PATH sys.path का अनुसरण करता है, (विंडोज़ शब्दों में) C: PythonXY से पहले %APPDATA%PythonXYScripts से पहले C:PythonXYScripts। मैं ध्यान दूंगा कि पायथन-देव धागे पर।

डोनाल्ड का नवीनतम प्रस्ताव मुझे अच्छा लगता है (मेरे मूल एक के साथ-साथ मेरे द्वारा छोड़े गए सभी महत्वपूर्ण विवरण :))। मैं "तो इसके बारे में और अधिक सोच रहा हूं ..." पैराग्राफ से भी 100% सहमत हूं।

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

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

इसे वास्तव में काम करने का एकमात्र तरीका पायथन इंस्टॉलर के लिए अनुरोध पर पाथ को कॉन्फ़िगर करने के लिए बैच फ़ाइलों को स्थापित करना शुरू करना है (और शायद एक शॉर्टकट जो बैच फ़ाइल चलाता है)। तो पहली चीज जो उपयोगकर्ता टाइप करेंगे वह है activate-py35 और फिर उनका PATH 3.5 के लिए सही तरीके से कॉन्फ़िगर किया गया है। मैं इस पर बहुत फटा हुआ हूं, क्योंकि मैं vcvarsall.bat स्थिति में नहीं आना चाहता, लेकिन साथ ही यह उन लिपियों के लिए बहुत अच्छा होगा जो वर्तमान में स्थापित स्थानों के बारे में धारणा बनाते हैं या कोशिश करते हैं और रजिस्ट्री के माध्यम से जाते हैं इसे खोजने के लिए।

और शायद एक शॉर्टकट जो बैच फ़ाइल चलाता है

मेरे दिमाग में, यह एक "पायथन 3.5 (32-बिट) कमांड प्रॉम्प्ट" शॉर्टकट है। विजुअल स्टूडियो उपयोगकर्ताओं को समानांतर को पहचानना चाहिए।

मैं विंडोज़ के बारे में इतना नहीं जानता कि इन सब के निहितार्थों को पूरी तरह से समझ सकें, लेकिन मुझे ऐसी स्थिति में वापस लौटने में बहुत बुरा लग रहा है जहां pip install foo जो एक स्क्रिप्ट स्थापित करता है foo तुरंत नहीं हो सकता कमांड लाइन पर foo के रूप में निष्पादित। अगर हम --user पर स्थापित कर रहे हैं और वह डिफ़ॉल्ट रूप से उनके रास्ते पर नहीं है तो यह मेरे लिए एक बहुत बड़ा प्रतिगमन जैसा लगता है।

मुझे यकीन नहीं है कि मैं वास्तव में समझता हूं कि अपरिवर्तित स्क्रिप्ट के लिए py.exe का उपयोग कैसे व्यवहार में काम करेगा और यह वास्तव में समस्या का समाधान करेगा या नहीं। मैं व्यक्तिगत रूप से स्क्रिप्ट बनाने से जुड़ा नहीं हूं जैसा कि हम आज हैं, इसलिए यदि यह _does_ काम करता है तो मुझे लगता है कि हम इसे कर सकते हैं लेकिन इससे पहले कि मैं इस पर अपना +1 दे सकूं, मुझे इसके प्रभावों को बेहतर ढंग से समझना होगा।

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

ओह, यक। मैं वह भूल गया था।

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

... जो हममें से उन लोगों के लिए भयानक है जो हर चीज के लिए पॉवरशेल में डिफ़ॉल्ट हैं।

लेकिन मुझे ऐसी स्थिति में वापस जाने के बारे में बहुत बुरा लगता है जहां pip install foo जो एक स्क्रिप्ट foo स्थापित करता है उसे तुरंत कमांड लाइन पर foo के रूप में निष्पादित नहीं किया जा सकता है।

माना। यह एक बुरा प्रतिगमन होगा, और इसे संबोधित करने की आवश्यकता है। मेरी इच्छा है कि कोई रास्ता सोच सके :-)

मुझे यकीन नहीं है कि मैं वास्तव में समझता हूं कि कैसे अपरिवर्तित स्क्रिप्ट के लिए py.exe का उपयोग अभ्यास में काम करेगा

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

... जो हममें से उन लोगों के लिए भयानक है जो हर चीज के लिए पॉवरशेल में डिफ़ॉल्ट हैं।

मैंने अभी कोशिश की है, और मैं आसानी से activate-py35.bat और activate-py35.ps1 फाइलें बना सकता हूं जो समान दिखती हैं और व्यवहार करती हैं (यानी, हर किसी को activate-py35 लिखना पड़ता है और पथ अपडेट हो जाते हैं)। अभी भी आदर्श नहीं है, लेकिन संभवतः सबसे खराब स्थिति का सबसे अच्छा है।

मुझे यकीन नहीं है कि मैं वास्तव में समझता हूं कि कैसे अपरिवर्तित स्क्रिप्ट के लिए py.exe का उपयोग अभ्यास में काम करेगा

मुझे लगता है कि बिंदु (जो केवल कुछ हद तक py.exe से संबंधित है) यह है कि एक्सई रैपर, एक विशिष्ट, हार्ड-कोडेड पायथन दुभाषिया को लागू करने के बजाय, जैसा कि यह वर्तमान में करता है, गतिशील रूप से "क्या" के आधार पर दुभाषिया का चयन करना चाहिए डिफ़ॉल्ट है" किसी तरह

"किसी तरह" वह जगह है जहाँ py.exe आता है - समान नियमों का उपयोग किया जाना चाहिए। यदि लॉन्चर को अपना नाम जांचने के लिए अपडेट किया गया था, तो python.exe लॉन्च करने के बजाय यह 'scripts\\{}{}.{}.exe'.format(argv[0], major_version, minor_version) ( argv[0] , आदि पर उपयुक्त एक्सटेंशन ट्रिमिंग के साथ) लॉन्च करने का प्रयास कर सकता था। फिर इंस्टॉलरों को पूरी तरह से संस्करण वाले (जो आज से अपरिवर्तित रहेगा) से असंक्रमित लॉन्चर के लिए एक अलग फ़ाइल का उपयोग करने की आवश्यकता है, लेकिन वह फ़ाइल एक नए नाम के साथ सामान्य py.exe होगी। (यह pip-script.py फाइलों के पुराने दिनों में और भी आसान हो सकता था, लेकिन अब वे चले गए हैं ...)

लेकिन जैसा कि आप कहते हैं, पथ अभी भी समस्या है। मेरे पास कोई अच्छा समाधान नहीं है, और यहां तक ​​कि कई बुरे समाधान भी नहीं हैं। पर्यावरण चर वास्तव में व्यवस्थापकों या उपयोगकर्ताओं को कॉन्फ़िगर करने के लिए हैं, इंस्टॉलर के लिए नहीं।

हम बेहतर उपयोगकर्ता अनुभव बनाने के लिए स्क्रिप्ट को स्थापित करने के तरीके को समायोजित कर सकते हैं। यह सब एक संतुलन है, संयुक्त .exe और .py फ़ाइल ने उपयोगकर्ताओं के लिए चीजों को अच्छा बना दिया है क्योंकि केवल एकवचन .exe फ़ाइल है। हालांकि मुझे लगता है कि pip install foo && foo के लिए सर्वश्रेष्ठ कहानी प्राप्त करना उस विशेष चीज़ से अधिक महत्वपूर्ण है, इसलिए यदि हमें .exe और .py को फिर से अलग करने की आवश्यकता है तो मुझे लगता है कि यह एक है एक अच्छे उत्तर के लिए अच्छा ट्रेडऑफ़।

.exe / .py अलगाव कम से कम समस्या है :)

मैं वास्तव में activate-py35 विचार को (या अनिच्छा से स्वीकार कर रहा हूं?) गर्म कर रहा हूं। मैं कभी भी पाथ में पाइथन जोड़ने वाले इंस्टॉलर का प्रशंसक नहीं रहा हूं, और py -m pip कमांड ने वास्तव में कर्षण प्राप्त नहीं किया है (और न ही यह स्फिंक्स के लिए काम करेगा)। मैं इस बारे में अधिक विस्तृत विवरण लिखूंगा कि activate-py कैसे काम कर सकता है और इसे पायथन-देव पर पोस्ट करके यह देखने के लिए कि क्या यह कोई कर्षण प्राप्त करता है।

क्या ये activate-whatever फाइलें वर्चुअल वातावरण के अंदर की फाइलों के समान होंगी? वर्चुअल वातावरण को $PATH में जोड़ने के बजाय यह असली पायथन जोड़ रहा है?

हाँ, काफी हद तक समान। पायथन-देव पर मैंने अभी सुझाव दिया है कि वे -x.y पैरामीटर लेंगे, इसे py.exe पर पास करेंगे और पथ प्राप्त करने के लिए sysconfig का उपयोग करेंगे।

ठीक। मेरे पास इस बारे में कोई राय नहीं है कि विंडोज उपयोगकर्ताओं के लिए यह कितना बुरा होगा क्योंकि मैं एक नहीं हूं। यह बिल्कुल भयानक नहीं लगता (शायद?) लेकिन यह लगभग उतना ही है जितना मेरा विंडोज ज्ञान मुझे ले सकता है।

10 फरवरी, 2015 को सुबह 08:02 बजे, डोनाल्ड स्टफ ने लिखा:

ओह, और स्क्रिप्ट क्लॉबरिंग बात एक अधिक सामान्य समस्या है जो नहीं है
वास्तव में --user से बिल्कुल संबंधित है। हर जगह मौजूद है यही समस्या
विंडोज --global इंस्टाल को छोड़कर। मुझे लगता है कि उस समस्या का समाधान है
एक माध्यमिक चिंता/समस्या जिसे हमें इस मुद्दे पर अलग से हल करना चाहिए।

माना।

हम --global ध्वज का उपयोग करने जा रहे हैं।

+1

यदि हम --user और
~/.local/bin $PATH पर नहीं है।

+1, शायद चेतावनी को दबाने के लिए एक कॉन्फ़िगरेशन विकल्प के साथ?

हम किसी प्रकार का default-install विकल्प चाहते हैं जो अनिवार्य रूप से होगा
फ़ॉलबैक व्यवहार को अक्षम करें और केवल हार्डकोड को --global या
--user ।

+1

पाइप 6.0 के अनुसार हमारे पास /etc/ . में स्थित मशीन विशिष्ट कॉन्फ़िगरेशन फ़ाइलें हैं
हालाँकि ये पायथन के उस संस्करण के लिए विशिष्ट नहीं हैं जो निष्पादित हो रहा है
पिप मुझे लगता है कि यह एक अच्छी सुविधा है, हालांकि कुछ हद तक अलग भी है (और
स्क्रिप्ट क्लॉबरिंग चीज़ को भी हल करने के साथ हाथ से जा सकता है)।

मैं एक खोज आदेश का सुझाव दूंगा जैसे:

• pipX.Y.conf
• pipX.conf
• पिप.conf

रूट पहले (?) /etc/xdg/pip फिर /etc, जहां XY निश्चित रूप से है
major.minor संस्करण संख्या। पहला मिला, जीत गया।

मुझे अभी भी एक प्रमुख खुला प्रश्न दिखाई दे रहा है: दीर्घकालिक हम क्या करना चाहते हैं जब
कोई sudo pip install foo करता है या इसके बजाय, अगर किसी के पास अनुमति है
site-packages निर्देशिका में लिखें?

कृपया ध्यान दें कि केवल एक "साइट-पैकेज" निर्देशिका नहीं है। उदाहरण के लिए,
डेबियन/उबंटू पर हम sudo pip install से _ever_ में स्थापित नहीं करना चाहते हैं
/usr/lib, लेकिन केवल /usr/स्थानीय/lib. और मत भूलो, यह यहाँ डिस्ट-पैकेज है
साइट-पैकेज नहीं (~/.लोकल को छोड़कर क्योंकि $reasons)।

यह वास्तव में एक महत्वपूर्ण बिंदु है जिसे कभी-कभी भुला दिया जाता है (यहां तक ​​कि मेरे द्वारा भी)।
डोनाल्ड इसका सबसे अच्छा वर्णन करता है जब वह कहता है कि एक साइट-स्थानीय निर्देशिका है और a
विक्रेता-स्थानीय निर्देशिका। डेबियन पर, साइट-स्थानीय is
/usr/lib/pythonX.Y/dist-packages और किसी भी पाइप कमांड को इसे कभी नहीं छूना चाहिए,
जबकि विक्रेता-स्थानीय /usr/local/lib/pythonX.Y/dist-packages है और यह एक है
कुछ सिस्टम प्रशासकों के लिए स्थापित करने के लिए प्रलेखित और लोकप्रिय उपयोग का मामला
उस निर्देशिका में।

तो मैं क्या सुझाव दूंगा, क्योंकि हम पहले से ही कॉन्फ़िगरेशन फ़ाइल पथ से नीचे हैं, to
इन्हें कॉन्फ़िगर करने योग्य बनाएं, उदाहरण के लिए

• Global_install_directory
• Global_install_as_sudo (सही/गलत)

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

उपरोक्त विन्यास के साथ, यह डेबियन के साथ पूरी तरह से संगत होगा।
डेबियन सुपरयूज़र sudo pip install में जाने की उम्मीद करते हैं
/usr/स्थानीय/lib/pythonX.Y/dist-packages. मैं यह नहीं कहूंगा कि "के साथ खिलवाड़"
सिस्टम" क्योंकि यह पैकेज मैनेजर को नहीं तोड़ता है, और जब तक यह कर सकता है
सिस्टम स्थापित संकुल को ओवरराइड करें (जो इसमें रहते हैं
/usr/lib/pythonX.Y/dist-packages), यह परिभाषित, प्रलेखित तरीके से ऐसा करता है।

1. में स्थापित करें --user , यह टूटे हुए सिस्टम से रक्षा करेगा (मुझे लगता है?)
   लेकिन मुझे नहीं लगता कि कोई भी रूट उपयोगकर्ता से एक प्राप्त करने की अपेक्षा करेगा
   /root/.local/ इंस्टॉल करें।

सहमत, यह अप्रत्याशित होगा।

1. बस त्रुटि हुई और उपयोगकर्ता को --user या . का चयन करने की आवश्यकता है
   --global मैन्युअल रूप से।

मैं इसके साथ ठीक रहूंगा, लेकिन ऊपर कॉन्फ़िगरेशन स्विच देखें।

1. पहले दो विकल्पों में से एक चुनें, लेकिन एक ऐसा स्विच प्रदान करें जो डिस्ट्रोस कर सके
   /etc/ में चालू करें जो तीसरे विकल्प को सक्षम करेगा।

अरे, क्या बढ़िया विकल्प है!

चौथा विकल्प सबसे अच्छा हो सकता है लेकिन मुझे लगता है कि हमें कोशिश करनी चाहिए
यदि हम किसी प्रकार के समाधान पर आ सकते हैं तो पहले अन्य विकल्पों में से एक का चयन करें
जो सभी प्लेटफार्मों/परिदृश्यों पर समान रूप से काम करता है और उन सभी पर समझ में आता है
जैसा कि यदि संभव हो तो मैं लगातार व्यवहार क्रॉस प्लेटफॉर्म रखना पसंद करूंगा।

मैं अलग, प्लेटफ़ॉर्म-परिभाषित व्यवहार के साथ ठीक हूं, यदि कहें, तो पाइप में a . था
--ड्राई-रन विकल्प जो कम से कम उपयोगकर्ता को बताएगा कि वह क्या कर रहा था
करने के लिए और कहाँ।

मुझे लगता है कि तीसरा विकल्प खराब होने की संभावना है, क्योंकि "मैंने लिखा है
अनुमति" परिदृश्य होने जा रहा है कि विंडोज़ पर कोई भी प्री
Python 3.5, या कोई भी जो Conda का उपयोग करता है, या कोई भी जो pyenv का उपयोग करता है। त्रुटिपूर्ण
उन सभी मामलों में गलत काम की तरह लगता है और कुछ हद तक उपयोगकर्ता है
बूट करने के लिए अमित्र।

मुझे खुशी होगी यदि डिफ़ॉल्ट कॉन्फ़िगरेशन को अनुमति दी जाए --global install यदि आप
अनुमति है। मुझे नहीं लगता कि डेबियन इसे बदलेगा (शायद दूसरों के पास)
एक अलग राय, लेकिन कम से कम यह हमें विकल्प देता है)।

तो मुझे लगता है कि 1 और 2 के बीच यह वास्तव में नीचे आता है कि अभ्यास कितना बुरा है
हमें लगता है कि यह (वैचारिक रूप से) लोगों के लिए है sudo pip install --global foo ।

डेबियन पर, यह एक अपेक्षित उपयोग का मामला है, जब तक यह /usr/local/lib पर जाता है।
यह /usr/lib पर नहीं जा सकता।

(यह सब बाहरी-ए-वेनव-व्यवहार बीटीडब्ल्यू का वर्णन करता है।)

• जब --user पास हो जाता है तो हम हमेशा उपयोगकर्ता साइट पैकेज में इंस्टॉल करते हैं।

+1

• जब --global पारित हो जाता है तो हम हमेशा वैश्विक साइट में स्थापित होते हैं
• पैकेज।

ग्लोबल _वेंडर_ पैकेज == +1, ग्लोबल साइट पैकेज == -1।

• जब न तो पारित किया जाता है तो हम एक फ़ॉलबैक विधि लागू करते हैं जो:
  
  
  
  1. पता लगाता है कि क्या हम एक आभासी वातावरण में हैं और यदि ऐसा है तो मानो
     
     --global पारित किया गया था।
  
  

+1, हालाँकि मैं दोहराता हूँ कि एक venv के अंदर इस निर्देशिका का नाम है
/lib/pythonX.Y/site-packages

1. पता लगाता है कि उपयोगकर्ता साइट-पैकेज अक्षम है या नहीं और यदि ऐसा है तो मानो
   --global पारित किया गया था।

हम्म, मैं इस बारे में निश्चित नहीं हूं।

1. default-install को देखता है और यदि वह मौजूद है तो --user या . का उपयोग करता है
   -global के आधार पर।

+1

1. पता लगाता है कि क्या प्रभावी उपयोगकर्ता के पास वैश्विक को लिखने की अनुमति नहीं है
   साइट पैकेज, और यदि वे कार्य नहीं करते हैं जैसे कि --user पारित किया गया था।

+1

1. अंत में, यदि अन्य सभी पता लगाने के तरीके विफल हो गए, तो कार्य करें जैसे कि --global
   पारित किया गया था।

भी निश्चित नहीं है।

इसका मतलब कोई मूल्यह्रास अवधि नहीं होगी और उम्मीद यह है कि
--user या --global की अनुपस्थिति में हम सर्वोत्तम अनुमान आधारित बनाने का प्रयास करेंगे
हम जिस पायथन में चल रहे हैं, उसकी क्षमताओं पर, प्रभावी उपयोगकर्ता, और
कोई भी कॉन्फ़िगर की गई डिफ़ॉल्ट इंस्टॉल विधि।

एक उचित लक्ष्य की तरह लगता है।

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

दूसरे शब्दों में, पाइप पहले से ही डिबंटू पर /usr/local/../dist-packages/ पर स्थापित हो गया है क्योंकि डेब्यू ने उस अंतर का समर्थन करने के लिए डिस्टुटिल्स को पैच कर दिया है। केवल एक ही समय में पाइप /usr/../dist-packages/ के साथ गड़बड़ करेगा, बिना उपयोगकर्ता किसी प्रकार के झंडे में गुजर रहा है कि पाइप वहां से फ़ाइलों की स्थापना रद्द कर देगा (क्योंकि पाइप उस निर्देशिका को विशेष के रूप में नहीं देखता है, यह सिर्फ इसे एक चीज़ के रूप में देखता है sys.path पर)। हालांकि डेबियन ने उस अनइंस्टॉल को रोकने के लिए पाइप को पैच किया है, और मुझे लगता है कि इसके लिए वास्तविक समर्थन पाइथन अपस्ट्रीम में "विक्रेता स्थानीय" साइट पैकेज के लिए वास्तविक समर्थन प्राप्त करने पर निर्भर है।

यदि हम --user में इंस्टाल कर रहे हैं और ~/.local/bin $PATH पर नहीं है, तो हम शायद किसी प्रकार की चेतावनी चाहते हैं

यह चेतावनी कितनी नाजुक हो सकती है? क्या यह निरपेक्ष पथ में परिवर्तित हो जाएगा? क्या यह केस असंवेदनशील फाइल सिस्टम के मामले में असंवेदनशील होगा? क्या यह विंडोज़ पर समकक्ष और / के रूप में व्यवहार करेगा? सिम्लिंक के बारे में क्या?

यदि आप एक ऐसा पैकेज स्थापित कर रहे हैं जो किसी भी स्क्रिप्ट को स्थापित नहीं करता है, तो चेतावनी वैसे भी अप्रासंगिक है।

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

यदि हम --user और
~/.local/bin $PATH पर नहीं है।

+1, शायद चेतावनी को दबाने के लिए एक कॉन्फ़िगरेशन विकल्प के साथ?

हम इसे केवल पायथन चेतावनियों का उपयोग कर सकते हैं ताकि लोग चुप रह सकें
यह अंतर्निहित पायथन चेतावनियों का उपयोग कर रहा है। अगर हमें इसे चुप कराने की आवश्यकता महसूस होती है
सब।

पाइप 6.0 के अनुसार हमारे पास /etc/ . में स्थित मशीन विशिष्ट कॉन्फ़िगरेशन फ़ाइलें हैं
हालाँकि ये पायथन के उस संस्करण के लिए विशिष्ट नहीं हैं जो निष्पादित हो रहा है
पिप मुझे लगता है कि यह एक अच्छी सुविधा है, हालांकि कुछ हद तक अलग भी है (और
स्क्रिप्ट क्लॉबरिंग चीज़ को भी हल करने के साथ हाथ से जा सकता है)।

मैं एक खोज आदेश का सुझाव दूंगा जैसे:

• pipX.Y.conf
• pipX.conf
• पिप.conf

रूट पहले (?) /etc/xdg/pip फिर /etc, जहां XY निश्चित रूप से है
major.minor संस्करण संख्या। पहला मिला, जीत गया।

इसे #2417 में विभाजित करें क्योंकि मेरा मानना ​​है कि यह केवल इसी से संबंधित है
विचार - विमर्श।

मुझे अभी भी एक प्रमुख खुला प्रश्न दिखाई दे रहा है: दीर्घकालिक हम क्या करना चाहते हैं जब
कोई sudo pip install foo करता है या इसके बजाय, अगर किसी के पास अनुमति है
site-packages निर्देशिका में लिखें?

कृपया ध्यान दें कि केवल एक "साइट-पैकेज" निर्देशिका नहीं है। उदाहरण के लिए,
डेबियन/उबंटू पर हम sudo pip install से _ever_ में स्थापित नहीं करना चाहते हैं
/usr/lib, लेकिन केवल /usr/स्थानीय/lib. और मत भूलो, यह यहाँ डिस्ट-पैकेज है
साइट-पैकेज नहीं (~/.लोकल को छोड़कर क्योंकि $reasons)।

यह वास्तव में एक महत्वपूर्ण बिंदु है जिसे कभी-कभी भुला दिया जाता है (यहां तक ​​कि मेरे द्वारा भी)।
डोनाल्ड इसका सबसे अच्छा वर्णन करता है जब वह कहता है कि एक साइट-स्थानीय निर्देशिका है और a
विक्रेता-स्थानीय निर्देशिका। डेबियन पर, साइट-स्थानीय is
/usr/lib/pythonX.Y/dist-packages और किसी भी पाइप कमांड को इसे कभी नहीं छूना चाहिए,
जबकि विक्रेता-स्थानीय /usr/local/lib/pythonX.Y/dist-packages है और यह एक है
कुछ सिस्टम प्रशासकों के लिए स्थापित करने के लिए प्रलेखित और लोकप्रिय उपयोग का मामला
उस निर्देशिका में।

तो मैं क्या सुझाव दूंगा, क्योंकि हम पहले से ही कॉन्फ़िगरेशन फ़ाइल पथ से नीचे हैं, to
इन्हें कॉन्फ़िगर करने योग्य बनाएं, उदाहरण के लिए

• Global_install_directory
• Global_install_as_sudo (सही/गलत)

पाइप वास्तव में इन्हें नियंत्रित नहीं करता है (मेरा मतलब है, जाहिर है उच्च स्तर पर यह करता है
क्योंकि यह चारों ओर घूमने वाली फाइलें हैं), वे distutils/sysconfig से आती हैं।

मुझे लगता है कि पाइप को कभी भी विक्रेता-स्थानीय निर्देशिका को तब तक नहीं छूना चाहिए जब तक
किसी प्रकार का झंडा --vendor दिया गया था जो विक्रेताओं को उपयोग करने में सक्षम करेगा
उनकी निर्माण श्रृंखला में पाइप। यह अवधारणा वास्तव में डिबंटू के बाहर मौजूद नहीं है
अभी और उनके पैच पहले से ही इसे संभालते हैं, इसलिए मुझे नहीं लगता कि यह सुपर है
इस चर्चा के लिए प्रासंगिक ध्यान देने के अलावा कि जब मैं कहता हूं
"वैश्विक साइट पैकेज" मेरा मतलब डेब्यूबंटू पर /usr/local/.../dist-packages था
और "साइट-स्थानीय" पैकेज किसी बिंदु पर यदि पायथन डेब्यू को स्वीकार करता है
सिस्टम अपस्ट्रीम।

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

उपरोक्त विन्यास के साथ, यह डेबियन के साथ पूरी तरह से संगत होगा।
डेबियन सुपरयूज़र sudo pip install में जाने की उम्मीद करते हैं
/usr/स्थानीय/lib/pythonX.Y/dist-packages. मैं यह नहीं कहूंगा कि "के साथ खिलवाड़"
सिस्टम" क्योंकि यह पैकेज मैनेजर को नहीं तोड़ता है, और जब तक यह कर सकता है
सिस्टम स्थापित संकुल को ओवरराइड करें (जो इसमें रहते हैं
/usr/lib/pythonX.Y/dist-packages), यह परिभाषित, प्रलेखित तरीके से ऐसा करता है।

हाँ, "सिस्टम के साथ खिलवाड़" बहुत कठोर हो सकता है। ज्यादातर मेरा मतलब है कि
sudo pip install foo अगर सिस्टम foo पर निर्भर करता है तो चीजें तोड़ सकती हैं और
आप चीजों का असंगत संस्करण स्थापित करते हैं। हालांकि वही मामला कायम है
मूल रूप से आपके द्वारा `/usr/स्थानीय`` में स्थापित किसी भी चीज़ के लिए सही है।

• जब --global पारित हो जाता है तो हम हमेशा वैश्विक साइट में स्थापित होते हैं
• पैकेज।

ग्लोबल _वेंडर_ पैकेज == +1, ग्लोबल साइट पैकेज == -1।

आपका मतलब यह दूसरी तरफ सही है?

• जब न तो पारित किया जाता है तो हम एक फ़ॉलबैक विधि लागू करते हैं जो:
  
  
  
  1. पता लगाता है कि क्या हम एक आभासी वातावरण में हैं और यदि ऐसा है तो मानो
     
     --global पारित किया गया था।
  
  

+1, हालाँकि मैं दोहराता हूँ कि एक venv के अंदर इस निर्देशिका का नाम है
/lib/pythonX.Y/site-packages

हाँ, हम फिर से सिर्फ पायथन से पूछते हैं कि वह निर्देशिका कहाँ है, हम इसकी गणना नहीं करते हैं
स्वयं, इसलिए "वह निर्देशिका कहाँ है" एक venv/virtualenv चीज़ है।

1. पता लगाता है कि उपयोगकर्ता साइट-पैकेज अक्षम है या नहीं और यदि ऐसा है तो मानो
   --global पारित किया गया था।

हम्म, मैं इस बारे में निश्चित नहीं हूं।

मुझे नहीं लगता कि इसके आसपास कोई रास्ता है, अगर उपयोगकर्ता साइट पैकेज अक्षम है I
यह मत सोचो कि हमें वहां स्थापित होना चाहिए क्योंकि हमारे पास जानने का कोई तरीका नहीं है
यदि उस अक्षम करने का अर्थ है _is_ कोई उपयोगकर्ता साइट-पैकेज नहीं है, या क्यों। हम ही कर सकते हैं
मान लीजिए कि कोई नहीं है।

1. अंत में, यदि अन्य सभी पता लगाने के तरीके विफल हो जाते हैं, तो कार्य करें जैसे कि --global
   पारित किया गया था।

भी निश्चित नहीं है।

यह मूल रूप से उबलता है:

अगर हमें कोई कारण नहीं मिलता है तो हमें --user का उपयोग करना चाहिए, जैसे कि --user झंडा, या
निर्देशिका में लिखने की अनुमति नहीं है, तो इसका उपयोग न करें। इस
वह है जो sudo pip install foo को बिना --global ध्वज के रखेगा
काम कर रहे। इसका मतलब यह भी है कि यह न तोड़ने के लिए सबसे महत्वपूर्ण नियम है
काम करने वाला सॉफ़्टवेयर जो इस तरह से कार्य करने के लिए sudo pip install foo की अपेक्षा करता है।

यदि हम --user में इंस्टाल कर रहे हैं और ~/.local/bin $PATH पर नहीं है, तो हम शायद किसी प्रकार की चेतावनी चाहते हैं

यह चेतावनी कितनी नाजुक हो सकती है? क्या यह निरपेक्ष पथ में परिवर्तित हो जाएगा? क्या यह केस असंवेदनशील फाइल सिस्टम के मामले में असंवेदनशील होगा? क्या यह विंडोज़ पर समकक्ष और / के रूप में व्यवहार करेगा? सिम्लिंक के बारे में क्या?

यदि आप एक ऐसा पैकेज स्थापित कर रहे हैं जो किसी भी स्क्रिप्ट को स्थापित नहीं करता है, तो चेतावनी वैसे भी अप्रासंगिक है।

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

वैसे हम इसे (क्रॉस प्लेटफॉर्म के समतुल्य) के रूप में लागू कर सकते हैं:

def user_bin_on_path():
    paths = os.environ.get("PATH").split(":")
    for path in paths:
        if os.path.realpath(path) == os.path.realpath(USER_BIN_DIR):
            return True
    return False

ऐसा कुछ सिम्लिंक, पथ विभाजक, और जैसा मुझे लगता है उसे संभालना चाहिए। विवरण में शैतान और शायद हम विभिन्न क्रॉस प्लेटफॉर्म कोने के मामलों को कवर करने के लिए पर्याप्त सटीक नहीं हो सकते हैं।

मैं सहमत हूं कि यदि कोई स्क्रिप्ट स्थापित नहीं की जा रही है तो चेतावनी अप्रासंगिक है, और मेरे कहने का मतलब यह था कि जब हम स्क्रिप्ट स्थापित कर रहे हों तो हम केवल चेतावनी से परेशान होंगे।

मूल विचार यह है कि मैं नहीं चाहता कि कोई pip install [--user] foo जैसा कुछ करे जहां --user निहित है, और फिर foo करें और बिना किसी मार्गदर्शन के "कमांड नहीं मिला" प्राप्त करें यह क्यों नहीं मिल सकता है। कम से कम एक चेतावनी उन्हें बताएगी कि उन्हें पाथ में चीजों को जोड़ने की जरूरत है। यह विंडोज़ पर उपयोगकर्ताओं को अपने उपयोगकर्ता डीआईआर को अपने पैथ में मैन्युअल रूप से जोड़ने में मदद कर सकता है (या इसे करने के लिए कुछ स्क्रिप्ट चला सकता है) जो स्टीव द्वारा इंगित activate स्क्रिप्ट की आवश्यकता को कम कर सकता है। हालांकि मुझे लगता है कि इसका अभी भी मतलब होगा कि सिस्टम मान उपयोगकर्ता मूल्यों पर पूर्वता लेते हैं ताकि अभी भी भ्रमित हो सके क्योंकि पाथ और sys.path के क्रम को अभी भी उलट दिया जाएगा।

दोह। मैं भूल गया कि realpath ने पथ को विहित किया। हाँ, निश्चित रूप से यह काफी अच्छा काम करता है।

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

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

10 फरवरी, 2015 को दोपहर 12:14 बजे, डोनाल्ड स्टफ ने लिखा:

मूल विचार यह है कि मैं नहीं चाहता कि कोई pip install [--user] foo जैसा कुछ करे जहां --user निहित है, और फिर foo करें और
बिना किसी मार्गदर्शन के "कमांड नहीं मिला" प्राप्त करें कि यह क्यों नहीं हो सकता है
मिला।

डेबियन, और शायद अन्य लिनक्स में, वास्तव में एक कमांड-न-पाया पैकेज है
जो उपयोगकर्ता को एक पैकेज स्थापित करने के लिए प्रेरित करता है यदि वे एक आदेश का आह्वान करते हैं कि
स्थापित नहीं है।

% इंकस्केप
प्रोग्राम 'इंकस्केप' वर्तमान में स्थापित नहीं है। आप इसे टाइप करके इंस्टॉल कर सकते हैं:
sudo apt-inkscape स्थापित करें

हो सकता है कि हम प्लेटफॉर्म का समर्थन करने के लिए उसमें शामिल हो सकें।

10 फरवरी, 2015 को दोपहर 12:06 बजे, डोनाल्ड स्टफ ने लिखा:

• जब --global पारित हो जाता है तो हम हमेशा वैश्विक साइट में स्थापित होते हैं
• पैकेज।

ग्लोबल _वेंडर_ पैकेज == +1, ग्लोबल साइट पैकेज == -1।

आपका मतलब यह दूसरी तरफ सही है?

मैं अपनी शब्दावली मिश्रित कर सकता था, इसलिए मैं स्पष्ट हो जाऊंगा:

/usr/स्थानीय/lib/pythonX.Y/dist-packages == +1
/usr/lib/pythonX.Y/dist-packages == -1

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

1. पता लगाता है कि उपयोगकर्ता साइट-पैकेज अक्षम है या नहीं और यदि ऐसा है तो मानो
   --global पारित किया गया था।

हम्म, मैं इस बारे में निश्चित नहीं हूं।

मुझे नहीं लगता कि इसके आसपास कोई रास्ता है, अगर उपयोगकर्ता साइट पैकेज अक्षम है I
यह मत सोचो कि हमें वहां स्थापित होना चाहिए क्योंकि हमारे पास जानने का कोई तरीका नहीं है
यदि उस अक्षम करने का अर्थ है _is_ कोई उपयोगकर्ता साइट-पैकेज नहीं है, या क्यों। हम ही कर सकते हैं
मान लीजिए कि कोई नहीं है।

ओह, मैं देखता हूं कि अब आपका क्या मतलब है। मुझे लगता है यह सार्थक बात है। मेरी चिंता यह है कि यह
यह अनुमान लगाना अधिक कठिन हो सकता है कि पाइप वास्तव में क्या करने जा रहा है, लेकिन जैसा कि I
कहो, मुझे --ड्राई-रन फ्लैग से खुशी होगी ताकि पाइप स्पष्ट रूप से _tell_ कर सके
आप यह क्या करने जा रहे हैं।

1. अंत में, यदि अन्य सभी पता लगाने के तरीके विफल हो जाते हैं, तो कार्य करें जैसे कि --global
   पारित किया गया था।

भी निश्चित नहीं है।

यह मूल रूप से उबलता है:

अगर हमें कोई कारण नहीं मिलता है तो हमें --user का उपयोग करना चाहिए, जैसे कि --user झंडा, या
निर्देशिका में लिखने की अनुमति नहीं है, तो इसका उपयोग न करें। इस
वह है जो sudo pip install foo को बिना --global ध्वज के रखेगा
काम कर रहे। इसका मतलब यह भी है कि यह न तोड़ने के लिए सबसे महत्वपूर्ण नियम है
काम करने वाला सॉफ़्टवेयर जो इस तरह से कार्य करने के लिए sudo pip install foo की अपेक्षा करता है।

समझा। मुझे लगता है कि यह ठीक है, क्योंकि मुख्य उपयोग-विरोधी मामले से हम बचना चाहते हैं:

normal_user$ पाइप फू स्थापित करें
अरे आपके पास कोई अनुमति नहीं है
normal_user$ sudo pip install foo
अरे आपने अभी-अभी अपना सिस्टम बोर किया है

और "निर्देशिका में लिखने की अनुमति नहीं होने का अर्थ है --user" नियम
इसका ख्याल रखता है।

अरे हाँ, मैं कमांड-नॉट-फ़ाउंड के बारे में भूल गया था। उपयोगी हो सकता है। वैसे क्या आप यह प्रस्तावित करने के लिए सही जगह जानते हैं कि डिफ़ॉल्ट रूप से पथ पर देवबटू में उपयोगकर्ता स्थानीय बिन है?

10 फरवरी 2015 को शाम 4:05 बजे बैरी वारसॉ नोटिफिकेशन @github.com ने लिखा:

10 फरवरी, 2015 को दोपहर 12:14 बजे, डोनाल्ड स्टफ ने लिखा:

मूल विचार यह है कि मैं नहीं चाहता कि कोई pip install [--user] foo जैसा कुछ करे जहां --user निहित है, और फिर foo करें और
बिना किसी मार्गदर्शन के "कमांड नहीं मिला" प्राप्त करें कि यह क्यों नहीं हो सकता है
मिला।

डेबियन, और शायद अन्य लिनक्स में, वास्तव में एक कमांड-न-पाया पैकेज है
जो उपयोगकर्ता को एक पैकेज स्थापित करने के लिए प्रेरित करता है यदि वे एक आदेश का आह्वान करते हैं कि
स्थापित नहीं है।

% इंकस्केप
प्रोग्राम 'इंकस्केप' वर्तमान में स्थापित नहीं है। आप इसे टाइप करके इंस्टॉल कर सकते हैं:
sudo apt-inkscape स्थापित करें

हो सकता है कि हम प्लेटफॉर्म का समर्थन करने के लिए उसमें शामिल हो सकें।

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

10 फरवरी, 2015 को दोपहर 01:17 बजे, डोनाल्ड स्टफ ने लिखा:

अरे हाँ, मैं कमांड-नॉट-फ़ाउंड के बारे में भूल गया था। उपयोगी हो सकता है। वैसे आप
यह प्रस्तावित करने के लिए सही जगह जानें कि देवबटू में उपयोगकर्ता स्थानीय बिन है
डिफ़ॉल्ट रूप से पथ?

निश्चित रूप से नहीं, लेकिन शायद एड्यूसर या पासवार्ड पैकेज? पूर्व मालिक
/usr/sbin/adduser और बाद वाला /usr/bin/useradd का मालिक है।

पहला पास: https://github.com/pypa/pip/pull/2418

मुझे यकीन नहीं है कि यह मदद करता है, लेकिन ...

• ~/.local/bin कई लोगों के $PATH पर नहीं है, क्या इस बारे में कुछ किया जा सकता है?

कुछ अन्य प्रोजेक्ट /etc/profiled.d/ का उपयोग $PATH में निर्देशिका जोड़ने के लिए करते हैं। कम से कम ऐंटरगोस पर मैं निम्नलिखित देखता हूं (जब तक कि मैं गलत नहीं समझता कि ये क्या करते हैं) jre.csh, jre.sh, perlbin.csh, perlbin.sh।

# Do not change this unless you want to completely by-pass Arch Linux' way
# of handling Java versions and vendors. Instead, please use script `archlinux-java`
setenv PATH "${PATH}:/usr/lib/jvm/default/bin"

# Do not change this unless you want to completely by-pass Arch Linux' way
# of handling Java versions and vendors. Instead, please use script `archlinux-java`
export PATH=${PATH}:/usr/lib/jvm/default/bin

# Set path to perl scriptdirs if they exist
# https://wiki.archlinux.org/index.php/Perl_Policy#Binaries_and_Scripts
# Added /usr/bin/*_perl dirs for scripts
# Remove /usr/lib/perl5/*_perl/bin in next release

[ -d /usr/bin/site_perl ] && setenv PATH ${PATH}:/usr/bin/site_perl
[ -d /usr/lib/perl5/site_perl/bin ] && setenv PATH ${PATH}:/usr/lib/perl5/site_perl/bin

[ -d /usr/bin/vendor_perl ] && setenv PATH ${PATH}:/usr/bin/vendor_perl
[ -d /usr/lib/perl5/vendor_perl/bin ] && setenv PATH ${PATH}:/usr/lib/perl5/vendor_perl/bin

[ -d /usr/bin/core_perl ] && setenv PATH ${PATH}:/usr/bin/core_perl

# If you have modules in non-standard directories you can add them here.
#export PERLLIB=dir1:dir2

# Set path to perl scriptdirs if they exist
# https://wiki.archlinux.org/index.php/Perl_Policy#Binaries_and_Scripts
# Added /usr/bin/*_perl dirs for scripts
# Remove /usr/lib/perl5/*_perl/bin in next release

[ -d /usr/bin/site_perl ] && PATH=$PATH:/usr/bin/site_perl
[ -d /usr/lib/perl5/site_perl/bin ] && PATH=$PATH:/usr/lib/perl5/site_perl/bin

[ -d /usr/bin/vendor_perl ] && PATH=$PATH:/usr/bin/vendor_perl
[ -d /usr/lib/perl5/vendor_perl/bin ] && PATH=$PATH:/usr/lib/perl5/vendor_perl/bin

[ -d /usr/bin/core_perl ] && PATH=$PATH:/usr/bin/core_perl

export PATH

# If you have modules in non-standard directories you can add them here.
#export PERLLIB=dir1:dir2

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

एक तरफ, मैं होमब्रू का उपयोग करता हूं और हमेशा इस तथ्य की सराहना करता हूं कि मैं केवल brew install something कर सकता हूं और यह अनुमतियों पर बिना किसी परेशानी के काम करेगा।

एक बार जब मुझे समझ में आ गया कि Homebrew के साथ इंस्टॉल करने के लिए sudo की आवश्यकता क्यों नहीं है, तो मैंने pip install --user something करने की आदत डालने की कोशिश की, लेकिन विडंबना यह है कि Homebrew इसे डिस्टुटिल्स में रिपोर्ट किए गए बग के कारण अक्षम कर देता है।

OS X पर Homebrew की लोकप्रियता को देखते हुए, शायद आप Homebrew और pip install --user की इस कथित असंगति को देखना चाहते हैं।

वैसे भी, --user को डिफ़ॉल्ट बनाने पर मुझसे +1।

एक त्वरित अनुवर्ती। डिडिएर ने उबंटू के पाइप में एक बदलाव को विशद रूप से अपलोड किया जो कि --user को डिफ़ॉल्ट के रूप में सेट करता है। मैंने ज्यादातर इसकी अनुमति भी दी थी, लेकिन अब मुझे लगता है कि यह एक गलती थी और मैं इसे वापस करने का इरादा रखता हूं (लेकिन शायद एसआरयू ज्वलंत के लिए एक बदलाव नहीं होगा)। विवरण और औचित्य के लिए https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1460203 देखें।

इस बदलाव के समय को अपस्ट्रीम ड्राइव देने के लिए +1, क्योंकि उपयोगकर्ता बनाम सिस्टम भेद पहले से ही प्लेटफॉर्म मतभेदों के बिना पर्याप्त भ्रमित कर रहा है।

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

मैंने @warsaw को निजी तौर पर बताया, लेकिन मैं इसे यहां भी कहूंगा:

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

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

शायद इस मोड़ पर दोहराने लायक:

यदि हम '--उपयोगकर्ता के लिए डिफ़ॉल्ट' के विरुद्ध निर्णय लेते हैं, तो हमें कम विघटनकारी विकल्पों पर विचार करना चाहिए

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

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

बस इस मुद्दे को +1 करने के लिए पॉप इन करना चाहता था और इस पर काम करने के लिए धन्यवाद कहना चाहता था! हम वर्तमान में एक वैज्ञानिक पायथन समर स्कूल चला रहे हैं और कई लोगों के पास sudo pip install है जब वे अनुमति के मुद्दों में भाग गए थे।

FWIW मैं डिफ़ॉल्ट रूप से --user , या --user पर वापस जाने के पक्ष में हूं यदि अनुमति त्रुटियों के कारण इंस्टॉल विफल हो जाता है। इस मामले में, मैं उन्हें असफल होने और उन्हें फिर से प्रयास करने का तरीका बताने के बजाय जो उन्होंने किया है उसे उलटने के लिए निर्देश देना पसंद करूंगा (उदाहरण के लिए, We installed to your user directory. If you don't want this, then 'pip uninstall my_package' )।

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

उन्होंने इसे _after_ dist-packages रखा है? यह एक टूटी हुई स्थापना आईएमओ है।

ठीक है, उपयोगकर्ता इंस्टॉल साइट (/ डिस्ट) -पैकेज से पहले होना चाहिए, और फिर सिस्टम स्क्रिप्ट और उपयोगिताओं को -I (या -ईएस पायथन 2 में) के साथ चलना चाहिए।

हाँ मैं सहमत हूँ :)। यह स्पष्ट रूप से तय किया जा सकता है, लेकिन मुझे निश्चित रूप से ऐसी रिपोर्टें मिली हैं जहां चीजें पूरी तरह से गलत जगह से आ रही हैं।

मैंने प्रयोग करने के लिए, अपनी ज्वलंत मशीन पर सेटपूल स्थापित करने के लिए सिस्टम पाइप का उपयोग किया।

>>> import setuptools
>>> setuptools.__path__
['/home/robertc/.local/lib/python2.7/site-packages/setuptools']
>>> import sys
>>> sys.path
['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/home/robertc/.local/lib/python2.7/site-packages', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PILcompat', '/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/pymodules/python2.7', '/home/robertc/work/mock']

तो यह समझदार है। लेकिन भ्रामक रूप से इसे विशद रूप से पेश किया गया था - इसलिए IDK। मैं देखूंगा कि क्या मैं किसी बिंदु पर एक पुनरुत्पादक खोद सकता हूं (उबंटू बीटीएस में फाइल करने के लिए)

पेजिंग @warsaw

उपयोक्ता साइट-पैकेजों को setuptools की बुराई .pth फ़ाइलों द्वारा वैश्विक साइट-पैकेज के बाद पुनर्व्यवस्थित किया जा सकता है। यह मेरे लिए एक आवर्ती समस्या थी जब तक कि मैंने सीधे setup.py का उपयोग नहीं करना सीखा - मैंने कुछ स्थापित किया, और अचानक मैं सभी प्रकार की अन्य चीजों के पुराने संस्करणों का उपयोग कर रहा था। कुछ समय बाद, मैंने अपने सिस्टम को अन-मैंगल करने के लिए एक आक्रामक टूल लिखा।

मुझे लगता है कि कम से कम, समय के लिए, पाइप को केवल एक दोस्ताना संदेश प्रिंट करना चाहिए जो उपयोगकर्ता को --user चलाने के लिए कहता है यदि आदेश विफल रहता है। इसे डिफ़ॉल्ट के रूप में स्विच करते समय इसके लाभ हैं, एक बेहतर संदेश प्रिंट करना बहुत कठिन नहीं होना चाहिए।

जब तक हम वास्तव में --user पर डिफ़ॉल्ट रूप से नहीं जाते हैं, तब तक यह समस्या के लिए एक अच्छा "त्वरित समाधान" है।

यदि उपयोक्ता मोड /etc/pip.conf में सेट है तो एक --global, --system, या --no-user भी आवश्यक है। जहां तक ​​मैं बता सकता हूं, उपयोगकर्ताओं के लिए इसे ओवरराइड करने का कोई आसान तरीका नहीं है।

यह समस्या के लिए एक अच्छा "त्वरित समाधान" है

देर से अपडेट: #4233 ने ऐसा किया।

जो लोग (विशेष रूप से नवागंतुक) विंडोज का उपयोग नहीं कर रहे हैं, उन्हें वास्तव में https://github.com/pyenv/pyenv पर निर्देशित किया जाना चाहिए यदि वे एक अच्छा अनुभव चाहते हैं। पीईपी 370 आज मेरे लिए बहुत मायने नहीं रखता, खासकर जब से ~/.local XDG_DATA_HOME है।

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

@jcrben pyenv इस बारे में कुछ धारणाएँ बनाता है कि लोग पायथन का उपयोग कैसे कर रहे हैं (और विशेष रूप से वे अपने पायथन बायनेरिज़ कैसे प्राप्त कर रहे हैं), जिसका अर्थ है कि यह उन लोगों के लिए बहुत अच्छा काम करता है जिनके लिए वे धारणाएँ मान्य हैं, लेकिन डिफ़ॉल्ट अनुशंसा होने के लिए पर्याप्त रूप से सार्वभौमिक नहीं है (यह उस संबंध में conda के समान है)।

--user डिफ़ॉल्ट pip स्तर पर ठीक से कॉन्फ़िगर किए गए पायथन वर्चुअल वातावरण के अंदर कोई प्रभाव नहीं पड़ेगा, इसलिए conda और pyenv जैसे तृतीय पक्ष पर्यावरण प्रबंधकों पर इस परिवर्तन का प्रभाव pip और अन्य उपकरण इसका पता लगा लेंगे (यानी जिस तरह से virtualenv इसकी रिपोर्ट करता है, या जिस तरह से मानक पुस्तकालय का venv करता है)।

संबंधित प्रस्ताव: https://github.com/pypa/pip/issues/1056#issuecomment -218130183।

~क्या उपयोगकर्ता को सीधे ~/.local में स्थापित करने से बचने के लिए निर्देशिका (शायद एक env चर के माध्यम से) को अनुकूलित करने की अनुमति दी गई है? मैं शायद उन्हें ~/.local/pip या कुछ और में घोंसला बनाना चाहता हूं - जहां तक ​​​​मेरा संबंध है पाइथन को उस साझा स्थान के शीर्ष स्तर पर कोई विशेष अधिकार नहीं है। ~ 9.0.1 पर ऐसा लगता है कि यह ~/.local/lib/python<version> के तहत सामान को घोंसला बनाता है और निष्पादन योग्य को ~/.local/bin में जोड़ता है जो मुझे लगता है कि ठीक है ...

@jcrben ऐ, लक्ष्य स्थान वास्तव में पायथन की उपयोगकर्ता साइट निर्देशिका है, जो सिस्टम साइट-पैकेज निर्देशिका के लिए नामकरण योजना को प्रतिबिंबित करती है: https://docs.python.org/3/library/site.html#site.USER_SITE

यह पहले से ही PYTHONUSERBASE पर्यावरण चर के माध्यम से दुभाषिया स्तर पर विन्यास योग्य है: https://docs.python.org/3/using/cmdline.html#envvar -PYTHONUSERBASE

रुचि रखने वालों के लिए, मैंने अभी जारी किया है https://github.com/ofek/hatch जिसमें पैकेज कमांड है install , uninstall , और update जो इस व्यवहार के लिए डिफ़ॉल्ट है। सिस्टम बदलने के लिए, उपयोगकर्ता https://github.com/npm/npm के समान -g/--global विकल्प का उपयोग कर सकते हैं।

PyPI पर मैलवेयर संक्रमित पैकेज के साथ हाल के मुद्दे को देखते हुए, मुझे लगता है कि यह पाइप के सर्वोत्तम हित में है कि वह sudo pip install ... के उपयोग को हतोत्साहित करने के लिए क्या कर सकता है, विशेष रूप से यह ध्यान में रखते हुए कि सेटअप स्क्रिप्ट स्थापना पर मनमाना कोड निष्पादित कर सकती है। एक उपयोगकर्ता के रूप में संक्रमित पैकेज स्थापित करना काफी खराब है, लेकिन अगर वे रूट के रूप में स्थापित हैं तो यह बहुत खराब है।

उपयोगकर्ता इंस्टॉल में चूक का मतलब है कि कम लोग sudo को अपने pip कमांड से जोड़ेंगे, जिसका अर्थ है कि गलती से इंस्टॉल किया गया मैलवेयर कम कर सकता है।

एक ठोस अगले कदम के रूप में, मैंने --global ध्वज जोड़ने के लिए एक अलग मुद्दा निकाला: https://github.com/pypa/pip/issues/4865

वर्चुअलएन्व या कोंडा वातावरण में यह लगभग निश्चित रूप से एक बुरा विचार है। एक वातावरण के सक्रिय होने पर .local में जो कुछ भी स्थापित हो जाता है वह आसानी से दूसरे वातावरण को तोड़ सकता है। तो उन मामलों में क्या सोच है?

cc @msarahan @kalefranz

यह समस्या तब लागू नहीं होती जब एक सक्रिय आभासी वातावरण के अंदर - यह केवल तभी लागू होता है जब कोई सक्रिय वातावरण नहीं पाया जाता है, और कोई भी लक्ष्य परिभाषा विकल्प ( --prefix , --root , आदि) नहीं दिया गया है कमांड लाइन पर।

यह कैसे तय किया जा रहा है?

@jakirkham https://github.com/ofek/hatch/blob/df2c9d46ee7713a1bc156c361cfd0f78e5935297/hatch/utils.py#L19-L25

हम कोंडा वातावरण के अंदर अजगर के लिए डिफ़ॉल्ट रूप से ~/.local पर sys.path पर अक्षम करने पर विचार कर रहे हैं, जो परिभाषा के अनुसार कोंडा द्वारा स्थापित कोई भी अजगर होता है। हालांकि यह मुश्किल है। किसी भी तरह से हम उपयोगकर्ताओं के समूह की अपेक्षाओं का उल्लंघन कर सकते हैं। https://github.com/conda/conda/issues/7173 पर चर्चा

क्या पाइप PIP_ से शुरू होने वाले पर्यावरण चर से किसी भी तर्क को लोड करने में सक्षम नहीं था? क्या यह --user के लिए काम करता है? पूर्ण परिवर्तनीय नाम क्या होगा?

वह PIP_USER होगा।

दस्तावेज़: https://pip.pypa.io/en/stable/user_guide/#environment -variables

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

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

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

यह उल्लेख करता है कि मुझे बैश में वर्चुअलएन्व का पता लगाना था और -यूसर को जोड़ने से बचना चाहिए या रन विफल हो जाएगा।

यह बदसूरत है और मुझे डिबगिंग में बहुत समय बर्बाद करने का कारण बना, मुझे यकीन है कि दूसरों को भी इसका सामना करना पड़ेगा।

मुझे लगता है कि हमें एक विकल्प की आवश्यकता है जो स्थापना के संबंध में एक फ़ॉलबैक को सक्रिय करता है: जैसे कि यदि आप कर सकते हैं तो इसे उपयोगकर्ता पर स्थापित करें और सिस्टम पर वापस आएं।

पाइप केवल तभी विफल होना चाहिए जब पैकेज स्थापित करने के लिए जगह खोजने में विफल हो।

इस पर कोई आंदोलन?

मैंने इसका उल्लेख नहीं देखा, लेकिन शायद पीआईपी को शिकायत करनी चाहिए कि सुडो के तहत चलाने पर - उपयोगकर्ता पास हो जाता है।

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

--user डिफ़ॉल्ट क्यों होगा? क्या इसे स्पष्ट रूप से निर्दिष्ट नहीं किया जा सकता है? मैं pip --target नहीं चला सकता क्योंकि यह शिकायत करता है कि इसका उपयोग उपयोगकर्ता के साथ संयोजन में नहीं किया जा सकता है। कोई विचार है कि इससे कैसे बचा जाए?

@dmikov : यह डिफ़ॉल्ट नहीं है। जब तक आप डेबियन/उबंटू टूटे हुए संस्करण का उपयोग नहीं कर रहे हैं, उस स्थिति में आप --user का उपयोग करके स्वचालित रूप से सेट होने का समाधान कर सकते हैं: PIP_USER=0 pip install -t ... । या बेहतर अभी तक, एक आधिकारिक संस्करण स्थापित करें और उसका उपयोग करें।

मैंने रात में सपना देखा है कि --user विकल्प डिफ़ॉल्ट (मजाक नहीं) बन रहा है, मेरे सपनों के जल्द ही सच होने का कोई मौका?

मुझे pygame स्थापित करने में सहायता चाहिए, यह अमान्य सिंटैक्स कहता रहता है

मैंनें इस्तेमाल किया
python3 -एम पाइप स्थापित करें -यू पायगेम --उपयोगकर्ता
क्या यह गलत है मैं क्या करूँ?

@ फ्लेमड्रो 56 : एक यादृच्छिक मुद्दे पर टिप्पणी करने के बजाय, कृपया एक नया खोलें, और अधिक जानकारी प्रदान करें: पायथन संस्करण, पाइप संस्करण, ऑपरेटिंग सिस्टम, कमांड आउटपुट ...

इंस्टॉलर रीकैप्चा

एक नया कॉन्फ़िगरेशन विकल्प डिफ़ॉल्ट = सिस्टम, उपयोगकर्ता होने के बारे में कैसे? यह पर्याप्त रूप से स्पष्ट होगा कि कोई भी यह नहीं सोचेगा कि इसका अर्थ "हमेशा उपयोगकर्ता, यहां तक ​​​​कि वर्चुअलएन्व में भी" है। यह एक सुंदर प्रवास पथ की अनुमति देगा।

#4575 देखें।

ऐसा लगता है कि मंज़रो --user को डिफ़ॉल्ट के रूप में सेट करने का प्रयास कर रहा है।

क्या इस मुद्दे के बारे में अपस्ट्रीम से कुछ नया है?

@Tids : "फाइलसिस्टम-2018.9-3 डिफ़ॉल्ट रूप से आपके $PATH में $HOME/.local/bin जोड़ता है।" महत्वपूर्ण अतिरिक्त टुकड़ा है जो मंज़रो सही कर रहा है।

उपयोगकर्ता खाता स्तर पर "$HOME/.local/bin डिफ़ॉल्ट रूप से आपके $PATH पर नहीं है" के साथ डेबियन पायथन स्तर पर "डिफ़ॉल्ट से --user" को जोड़ती है, और वह कॉम्बो है जो चीजों को तोड़ता है।

#7002 में, जब वैश्विक साइट-पैकेज डीआईआर लिखने योग्य नहीं है, और उपयोगकर्ता साइट-पैकेज सक्षम हैं, तो मैंने डिफ़ॉल्ट रूप से उपयोगकर्ता को पीआईपी स्थापित करने का प्रयास किया है। जब आप किसी env में इंस्टाल करना चाहते हैं तो यह काफी हद तक यूजर इंस्टाल करने से बचना चाहिए, जब तक कि आपके पास env को संशोधित करने की अनुमति है।

मैं पहले विचार की चर्चा की तलाश कर रहा हूं - इससे पहले कि हम इस बारे में सोचें कि क्या यह उस काम को करने के लिए समझ में आता है, इससे पहले कि हम कार्यान्वयन की समीक्षा करने में न उलझें।

यह ध्यान देने योग्य है कि उपयोगकर्ता इंस्टॉल और गैर-उपयोगकर्ता इंस्टॉल (पाइप के ही) को मिलाना मुद्दों से भरा है - हाल ही में एक उदाहरण के रूप में #7209 देखें।

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

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

ऐसा लगता है कि समस्या यह है कि PATH (कमांड खोजने के लिए) और sys.path (पायथन आयात खोजने के लिए) की विपरीत प्राथमिकताएं हैं, इसलिए एक इंस्टॉलेशन से लॉन्चर स्क्रिप्ट पैकेज को लोड करने का प्रयास करती है अन्य। यह संभवतः पाइप के लिए विशिष्ट नहीं है - यह किसी भी पैकेज को प्रभावित कर सकता है जो एक स्क्रिप्ट स्थापित करता है।

मुझे नहीं पता कि हम उसके बारे में क्या कर सकते हैं, लेकिन मैं मानता हूं कि यह सोचने लायक है।

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

आपका मतलब है pip रैपर स्क्रिप्ट को बहिष्कृत करना, या रैपर स्क्रिप्ट को एक चीज के रूप में बहिष्कृत करना जो पाइप स्थापित कर सकता है?

मैं निश्चित रूप से बाद में -1 हूं - कमांड स्थापित करने की क्षमता बहुत उपयोगी है, भले ही यह समस्याएं पैदा करता हो।

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

मेरा मतलब विशेष रूप से पाइप के लिए रैपर स्क्रिप्ट से था। सहमत हूं कि यह सुविधा का नुकसान है, और मैं उन्हें किसी रूप में बनाए रखने के खिलाफ नहीं होगा (#3164 एक नया pip-cli प्रोजेक्ट होने का सुझाव देता है जो सिर्फ रैपर की आपूर्ति करता है) लेकिन मुख्य बिंदु python -m pip के लिए होगा समर्थित साधन होना।

यदि वर्तमान python (पथ में या जो कुछ भी python -m pip के साथ उपयोग किया जाएगा) पाइप रैपर स्क्रिप्ट को कॉल नहीं कर सका, तो वह python द्वारा उपयोग किया गया pip नहीं है। python -m pip को भी प्रतिनिधि दें?

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

ठीक है, यहां यह ध्यान में रखते हुए कि #7002 को इस बिंदु पर 6 में से 3 पाइप अनुरक्षकों द्वारा अनुमोदित किया गया है।

यह डिफ़ॉल्ट रूप से गैर-उपयोगकर्ता इंस्टॉल से उपयोगकर्ता इंस्टॉल पर पाइप स्विच करता है, ज्यादातर मामलों में जहां हमें वास्तव में उपयोगकर्ता इंस्टॉल करना चाहिए। इस परिवर्तन को करने के साथ मेरी दो व्यापक चिंताएँ हैं, कि हमें उस रिलीज़ को करने से पहले पता लगाना चाहिए जो उस वृद्धि को करती है।

• एक बार डिफ़ॉल्ट रूप से स्विच करने के बाद क्या हम उपयोगकर्ता इंस्टॉल से स्पष्ट रूप से ऑप्ट-आउट करने के लिए एक तंत्र चाहते हैं? यदि हां, तो यह --no-user से किस प्रकार भिन्न होगा? (मैं स्पष्ट ऑप्ट-आउट के रूप में --no-user से --global का नाम बदलने के लिए तैयार हूं)।
• हमारी "संक्रमण" रणनीति क्या है?
  
  
  
  • हम इस परिवर्तन को कैसे संप्रेषित करना चाहते हैं?
  
  
  • यह अपग्रेड करते समय उपयोगकर्ताओं को सावधान रहने के लिए कहें?
  
  
  • जब यह परिवर्तन लागू + जारी किया जाता है, तो हम उपयोगकर्ताओं से किस प्रकार के मुद्दों को उठाने की उम्मीद करते हैं?
  
  

मैं कहूंगा कि --global गलत नाम है यदि आप किसी वातावरण के अंदर हैं। flit install के लिए, --user के विपरीत --env है, जिसका अर्थ है "सिस्टम पायथन पर्यावरण" को शामिल करना, लेकिन मुझे नहीं लगता कि यह पूरी तरह से स्पष्ट है। शायद --no-user अभी भी सबसे अच्छा विकल्प है - यह स्पष्ट रूप से --user के विपरीत है।

मुझे लगता है कि --no-user (या समकक्ष पर्यावरण चर या कॉन्फ़िगरेशन प्रविष्टि) आपको मौजूदा व्यवहार को वापस लेना चाहिए, क्योंकि वर्तमान में डिफ़ॉल्ट प्रभावी रूप से user = False है।

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

यह भी संभव है कि लेखन क्षमता का पता लगाना गलत हो सकता है। एक झूठा सकारात्मक आपको केवल मौजूदा व्यवहार देता है (सामान्य इंस्टॉल करने का प्रयास करें और विफल)। एक गलत नकारात्मक एक उपयोगकर्ता को तब स्थापित करेगा जब वह एक सामान्य काम कर सकता था।

यह डिफ़ॉल्ट रूप से गैर-उपयोगकर्ता इंस्टॉल से उपयोगकर्ता इंस्टॉल पर पाइप स्विच करता है।

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

यह कहने के बाद:

1. ऐसा लगता है कि --no-user विकल्प का कोई मतलब नहीं है, क्योंकि #7002 का अर्थ है कि आप एक उपयोगकर्ता को केवल तभी स्थापित करते हैं जब कोई सिस्टम इंस्टॉल विफल हो जाता है।
2. सबसे बड़ी बात जो मुझे लगता है कि हमें संक्रमण के बारे में संवाद करने की आवश्यकता है, वह यह है कि लोगों को कई इंस्टॉल के बारे में बहुत सावधान रहने की जरूरत है, और यह कुछ ऐसा है जिसे केवल उपयोगकर्ता की समझ और शिक्षा से ही निपटा जा सकता है, न कि पीआईपी में किसी भी कामकाज से। यह मूल रूप से एक मूल पायथन मुद्दा है। हम रिपोर्ट करने के लिए pip check का विस्तार कर सकते हैं जब कोई साइट और उपयोगकर्ता पैकेज की स्थापना करता है और उपयोगकर्ता साइट को छायांकित कर रहा है, मुझे लगता है ...

ऐसा लगता है कि --no-user विकल्प का कोई मतलब नहीं है

स्पष्ट होने के लिए, यह पहले से मौजूद है, हालांकि यह शायद अक्सर उपयोगी नहीं होता है। यदि आपके पास कॉन्फ़िगरेशन फ़ाइल में user=true है, तो --no-user को इसे ओवरराइड करना चाहिए।

स्पष्ट होने के लिए, यह पहले से मौजूद है

क्षमा करें, मुझे और स्पष्ट होना चाहिए था। मुझे "डिफ़ॉल्ट रूप से स्विच करने के बाद उपयोगकर्ता इंस्टॉल से स्पष्ट रूप से ऑप्ट-आउट करने के लिए एक तंत्र" होने का कोई मतलब नहीं दिखता है, कम से कम इस अर्थ में कि मुझे लगता है कि @pradyunsg का मतलब है, जो # 7002 व्यवहार से बाहर निकलने के बारे में है, जो जैसा कि मैंने कहा, "डिफ़ॉल्ट रूप से उपयोगकर्ता इंस्टॉल पर स्विच करना" जैसा नहीं है।

असल में, मुझे यकीन नहीं है कि यह कोई स्पष्ट है ;-) शायद मैं केवल इतना कहना चाहता हूं कि "हमें वर्तमान में मौजूद विकल्पों की तुलना में किसी और विकल्प की आवश्यकता नहीं है" ...

हम्म... @pfmoore #7002 के बाद, इस समस्या को हल करने के लिए क्या करने की आवश्यकता है?

पीएस: मैंने जल्दी में उस पहले टिप्पणी को लिखा था और इसे गलती से पोस्ट किया गया था। गोलियां ठीक हैं; मैं अभी भी इससे पहले पैराग्राफ का मसौदा तैयार कर रहा था, जब इसे पोस्ट किया गया। इसके कारण हुई किसी भी भ्रम के लिए क्षमा करें।

@pradyunsg यह देखते हुए कि मैं अब यह महसूस करने के लिए बहुत कम इच्छुक हूं कि --user डिफ़ॉल्ट के रूप में एक अच्छा विचार है जब तक कि यह बिल्कुल आवश्यक न हो (मामलों # 7002 पते) मैं यह कहूंगा कि हम इस मुद्दे को छोड़ सकते हैं अब कोई अच्छा विचार नहीं है कि #7002 हो गया है।

आपके 2 बुलेट पॉइंट्स को चीजों के रूप में लेते हुए हमें #7002 को पूर्ण रूप से गिनने की आवश्यकता हो सकती है, ऊपर दी गई मेरी टिप्पणियां इसे कवर करती हैं।

मैंने यहां रिलीज नोट्स का पालन किया।
https://pip.pypa.io/hi/stable/news/#id3
"उपयोगकर्ता स्थापित करने के लिए डिफ़ॉल्ट (जैसे कि --user पारित किया गया था) जब मुख्य साइट-पैकेज निर्देशिका लिखने योग्य नहीं है और उपयोगकर्ता साइट-पैकेज सक्षम हैं। (#1668)"

मेरे निर्माण अब विफल हो रहे हैं

ERROR: Can not perform a '--user' install. User site-packages are not visible in this virtualenv.

यह मेरे पाइप कमांड से --user को हटाकर तय किया गया लगता है।

क्या यह अपेक्षित व्यवहार था? ऐसा प्रतीत नहीं होता कि रिलीज़ नोट इसे प्रतिबिंबित करते हैं।

स्क्रिप्ट का लिंक जो अब पाइप 20.0.1 पर विफल हो जाता है (--user को हटाकर हार्ड फेल को ठीक करता है)
https://github.com/lfit/releng-global-jjb/blob/master/shell/python-tools-install.sh

यदि यह सही है कि उपयोगकर्ता साइट पैकेज उस वातावरण से आयात करने योग्य नहीं हैं, तो यह अपेक्षित व्यवहार है, लेकिन यह इस पीआर के लिए ऑर्थोगोनल है। वह चेक सालों पहले (#567) पेश किया गया था, लेकिन ऐसा लगता है कि हाल ही में (#7155) तक इसे venv से तोड़ा गया था। उसके लिए एक रिलीज़ नोट है:

वेनव (पीईपी 405) के साथ बनाए गए वर्चुअल वातावरण में सिस्टम साइट-पैकेज को सही ढंग से संभालें।

आह हाँ, आपकी टिप्पणियों के लिए धन्यवाद। मुझे यह पता चल गया...
मेरी स्क्रिप्ट पॉप्युलेट कर रही थी .local/bin/
जब मैं भागा

python3 -m venv ~/.local

और फिर एक ubuntu लॉगिन शेल में (#!/bin/bash -l) .local/bin पथ में जुड़ जाता है (इसलिए python3 को कॉल करना अब .local/bin/python3 निष्पादन योग्य को कॉल करता है) जो हम नहीं चाहते हैं।
मुझे कभी भी python3 -m venv चलाने की जरूरत नहीं पड़ी ~/.local
या मेरी स्क्रिप्ट को एक लॉगिन शेल से कॉल करें, और दोनों या इनमें से किसी एक समस्या को दूर करने से यह ठीक हो जाता है।

#fresh ubuntu docker
root<strong i="13">@7d8107816f64</strong>:/# python3 -m pip install  --user --upgrade pip
Successfully installed pip-20.0.1
root<strong i="14">@7d8107816f64</strong>:/# python3 -m pip --version
pip 20.0.1 from /root/.local/lib/python3.6/site-packages/pip (python 3.6)
root<strong i="15">@7d8107816f64</strong>:/# ls root/.local/bin/pip
pip     pip3    pip3.6
#Now we populate ~/.local/bin/
root<strong i="16">@7d8107816f64</strong>:/# python3 -m venv ~/.local
root<strong i="17">@7d8107816f64</strong>:/# ls root/.local/bin/
activate          activate.fish     easy_install-3.6  pip3              python
activate.csh      easy_install      pip               pip3.6            python3
root<strong i="18">@7d8107816f64</strong>:/# ./root/.local/bin/python --version
Python 3.6.9
root<strong i="19">@7d8107816f64</strong>:/# ./root/.local/bin/python -m pip install  --user --upgrade pip
ERROR: Can not perform a '--user' install. User site-packages are not visible in this virtualenv.

इसलिए यदि हम कभी भी एक्ज़ीक्यूटेबल .लोकल/बिन/पायथन चलाते हैं तो हम --user . के साथ पाइप इंस्टाल नहीं कर सकते हैं

ओह, मुझे याद आया कि आप python3 -m venv ~/.local कर रहे थे। यह पाइप जैसे टूल को भ्रमित करने की संभावना है, क्योंकि ~/.local --user इंस्टॉल (लिनक्स पर) के लिए उपसर्ग है। venvs और --user दो _भिन्न_ तरीके हैं जिनसे आप सिस्टम में बदलाव किए बिना पैकेज स्थापित कर सकते हैं: आपको एक या दूसरे का उपयोग करना चाहिए। ~/.local में एक वेनव बनाना दोनों के कुछ अजीब संकर बनाता है।

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

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

अन्य लोगों के लिए जिन्हें समान समस्याएं हुई हैं, इसके लिए कुछ तरीके हैं:

• स्क्रिप्ट आदि में अपने सभी pip install कमांड लाइन में --force-reinstall जोड़ें
• ~/.local/lib/python* हटाएं और global अनुभाग में user = no जोड़ने के लिए ~/.pip/pip.conf संपादित करें:

[global]
user = no

• कुछ अधिक कठोर करें, जैसे ~/.local/lib को किसी निर्देशिका के बजाय फ़ाइल में बदलें :smirk:

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

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

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

यदि आप --system-site-packages विकल्प (या वर्चुअलएन्व के बहुत पुराने संस्करण जहां वह डिफ़ॉल्ट था) के साथ वर्चुअलएन्व बनाते हैं, तो वे उन पैकेजों पर ओवरले के रूप में कार्य करते हैं जिन्हें आपने अन्यथा स्थापित किया होता, दोनों सिस्टम-वाइड और आपके घर में निर्देशिका। यदि आप चाहते हैं कि सिस्टम पैकेज दृश्यमान हों, लेकिन उपयोगकर्ता पैकेज न हों, तो आप -s विकल्प या PYTHONNOUSERSITE पर्यावरण चर के साथ पायथन चला सकते हैं।

ओह! मुझे बहुत खेद है, तुम बिल्कुल सही हो। मेरे संगठन की अजीब प्रणाली-साइट-पैकेज नीति फिर से हमला करती है। कुछ समाधान इंगित करने के लिए धन्यवाद।

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

https://github.com/pypa/pip/issues/1668#issuecomment -544569965 के अनुरूप समापन।

बहुत धन्यवाद @takluyver! ^>^

@takluyver उस समस्या को हल करने के लिए धन्यवाद जिसने मुझे लंबे समय से परेशान किया है
लेकिन मैंने देखा कि गैर-विशेषाधिकार प्राप्त उपयोगकर्ताओं के साथ पैकेज स्थापित करते समय, पीआईपी 20.0.2 के साथ विंडोज 10 पायथन 3.8.2 अभी भी कठिन असफल रहा है।

ERROR: Exception:
Traceback (most recent call last):
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\cli\base_command.py", line 186, in _main
    status = self.run(options, args)
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\commands\install.py", line 253, in run
    options.use_user_site = decide_user_install(
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\commands\install.py", line 604, in decide_user_install
    if site_packages_writable(root=root_path, isolated=isolated_mode):
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\commands\install.py", line 548, in site_packages_writable
    return all(
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\commands\install.py", line 549, in <genexpr>
    test_writable_dir(d) for d in set(get_lib_location_guesses(**kwargs))
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\utils\filesystem.py", line 140, in test_writable_dir
    return _test_writable_dir_win(path)
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\utils\filesystem.py", line 153, in _test_writable_dir_win
    fd = os.open(file, os.O_RDWR | os.O_CREAT | os.O_EXCL)
PermissionError: [Errno 13] Permission denied: 'c:\\program files (x86)\\python38-32\\Lib\\site-packages\\accesstest_deleteme_fishfingers_custard_m59lch'

मैंने सोचा था कि यह OSError के errno के कारण हो सकता है $ errno.EACCES लेकिन errno.EPERM ।

@catPill कृपया एक नया मुद्दा खोलें ताकि इसे ठीक से ट्रैक किया जा सके। यह पूरी तरह से प्रशंसनीय है कि मुझे विंडोज़ पर कुछ याद आया।