/cc @uranusjr @ncoghlan @altendky @njsmith

मुझे विश्वास है कि यह एक ऐसी चीज है जो आम तौर पर होती है (कॉर्पोरेट परिवार कल्याण/कैशिंग प्रॉक्सी) - मुझे लगता है कि हमें पीपीआई के बजाय उपयोग करने के लिए एक दर्पण निर्दिष्ट करने के लिए ओवरराइड सेटिंग की आवश्यकता है यदि हम इसे पाइपफाइल में पाते हैं- जैसे PIPENV_PYPI_MIRROR या PIPENV_PYPI_CACHING_PROXY या ऐसा कुछ निर्दिष्ट करने के लिए कि इसे पहले कोशिश की जानी चाहिए, मूल रूप से पीपीआई के सामने sources में कटा हुआ।

क्या ऐसा लगता है कि यह लक्ष्य पूरा करता है? यदि ऐसा है, तो हम कार्यान्वयन जिन्न में टैग करके हमें बता सकते हैं कि यह अच्छा या बुरा क्यों है (@ncoghlan)

मैं सावधानी के साथ शुरू करूंगा: जब तक पीईपीआई ने पीईपी 458 के समान एक पैकेज हस्ताक्षर तंत्र लागू नहीं किया है, तब तक pip के लिए टीएलएस-स्वतंत्र तरीका प्रदान करने के लिए यह सुनिश्चित करने के लिए कि पैकेज जो नाममात्र पीईपीआई से उत्पन्न होते हैं, वास्तव में पीपीपीआई द्वारा प्रकाशित से मेल खाते हैं , फिर किसी भिन्न सर्वर पर ट्रैफ़िक को पारदर्शी रूप से पुनर्निर्देशित करने की क्षमता प्रदान करना वास्तव में सुरक्षा के दृष्टिकोण से संबंधित है।

दुर्भाग्य से, वह विशेष हमला वेक्टर पहले से ही pip.conf के माध्यम से खुला है, इसलिए pipenv स्तर पर तुलनीय कुछ की पेशकश करने से कुछ भी पहले से भी बदतर नहीं होने वाला है।

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

pipenv --override-source-url 'default=https://pypi-proxy.example.com/api' --override-source-url 'https://pypi.python.org/simple=https://pypi-proxy.example.com/api'  --override-source-url 'https://pypi.org/simple=https://pypi-proxy.example.com/api' install

(पाइप के डिफ़ॉल्ट डाउनलोड स्रोत को संदर्भित करने के लिए केवल पीईपीआई विशिष्ट बिट "डिफ़ॉल्ट" का उपयोग करेगा, जैसा कि pip.conf में विशिष्ट है)।

संपूर्ण स्रोत URL ओवरराइड मैप की वर्तनी हर बार व्यवहार में उपयोग करने के लिए बोझिल होगी, इसलिए सीएलआई चीनी के लिए कुछ विकल्प इस तरह दिख सकते हैं:

pipenv --override-source-urls <config file> install

pipenv --pypi-mirror https://pypi-proxy.example.com/api install

--override-source-url परत को तुरंत उजागर किया जाए या नहीं, यह एक अलग सवाल है - यह पहले सरल --pypi-mirror विकल्प को लागू करने के लिए अधिक समझ में आता है, और केवल --override-source-url की संभावना को बनाए रखता है और --override-source-urls ऐसा करते समय भविष्य के संभावित विकल्पों को ध्यान में रखें।

एक सामान्य {given URL: override URL} मैपिंग मेरा पहला विचार भी था, लेकिन आगे विचार करने पर, विशेष-आवरण पीईपीआई के लिए कुछ तर्क हैं:

• एक प्रसिद्ध सार्वजनिक URL और बहुत सारे दर्पण होने के कारण PyPI बहुत ही अनूठा है

• पीईपीआई में वास्तव में कई यूआरएल हैं (उदाहरण के लिए, शायद हमारे पास https://pypi.python.org/simple और https://pypi.org/simple और शायद https://pypi.python.org/simple/ और https://pypi.org/simple/ दोनों के साथ कुछ समय के लिए पिपफाइल्स तैरते रहेंगे।

@njsmith मेरी पोस्ट के अंतिम भाग में --pypi-mirror <URL> चीनी सुझाव देखें - यदि प्रारंभिक कार्यान्वयन केवल उस पर केंद्रित है, तो सामान्य URL पुनर्लेखन क्षमता आंतरिक कार्यान्वयन विवरण के रूप में शुरू हो सकती है (इस तथ्य से प्रेरित है कि " PyPI" में कई यूआरएल हैं जो अंततः एक ही स्थान पर हल हो जाते हैं), और फिर बाद में अपने आप में एक विशेषता के रूप में एक्सपोजर के लिए विचार किया जाता है (यह पुष्टि होने के बाद कि यह प्राथमिक --pypi-mirror उपयोग के लिए वांछित के रूप में काम कर रहा है मामला)।

आह, ठीक है, मुझे याद आया :-)

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

@ncoghlan ने लिखा:

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

अगर मैं अपना Pipfile.lock सही ढंग से पढ़ रहा हूं तो पैकेज के बीच कोई संबंध संग्रहीत नहीं है और यह किस स्रोत से स्थापित किया गया था। यह देखते हुए कि मौजूदा फीचरसेट कई स्रोतों को निर्दिष्ट करने की अनुमति देता है, क्या यह एक समान समस्या नहीं बना रहा है? एक sync एक अलग स्रोत से एक पैकेज प्राप्त कर सकता है जो कि लॉकफाइल बनाते समय उपयोग किया गया था।

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

pip.conf में डिफ़ॉल्ट इंडेक्स यूआरएल (या एक अतिरिक्त इंडेक्स यूआरएल जोड़ना) बदलना, या कॉन्फ़िगरेशन फ़ाइल या शैल प्रोफाइल आधारित तंत्र के माध्यम से यहां प्रस्तावित ओवरराइड सुविधा का उपयोग करना अलग है: यह कह रहा है "मैं, या कुछ मनमानी प्रक्रिया I मेरी होम निर्देशिका (जैसे एक sdist की setup.py फ़ाइल) में लेखन पहुंच के साथ किसी समय पर चला, पैकेज के इस स्रोत पर भरोसा करने के लिए मेरी सेटिंग्स को कॉन्फ़िगर करने का निर्णय लिया"। और यहां तक ​​​​कि पीईपी 458 जैसी एक हस्ताक्षर योजना उन प्रकार के शेंगेनियों के खिलाफ पूर्ण रक्षा नहीं है यदि सत्यापन के लिए उपयोग की जाने वाली सार्वजनिक कुंजी स्वयं आपके होम निर्देशिका के अंदर कहीं संग्रहीत की जाती है, न कि किसी निर्देशिका में जिसे संशोधित करने के लिए उन्नत विशेषाधिकारों की आवश्यकता होती है।

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

ध्यान दें कि यदि आप एकाधिक अनुक्रमणिका का उपयोग करते हैं और पैकेज गैर-प्राथमिक अनुक्रमणिका से आता है तो इसे लॉकफ़ाइल में इंगित किया जाएगा।

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

मैंने, या कुछ मनमानी प्रक्रिया जो मैंने अपनी होम निर्देशिका (जैसे कि एक sdist की setup.py फ़ाइल) में लेखन पहुंच के साथ किसी समय में चलाई, पैकेज के इस स्रोत पर भरोसा करने के लिए मेरी सेटिंग्स को कॉन्फ़िगर करने का निर्णय लिया

यदि यह आपका खतरा मॉडल है, तो मैं नहीं देखता कि पिपेनव जो कुछ भी कर सकता है वह इसे कितना प्रभावित करेगा। कोई व्यक्ति जो आपके होम डायरेक्टरी कॉन्फिगर को संशोधित कर सकता है, वह $PATH पर एक नई डायरेक्टरी डालने जैसे काम भी कर सकता है और वहां एक नकली पिपेनव डालें जो वे चाहते हैं।

@njsmith यह भी पाइप का खतरा मॉडल है, क्योंकि पैकेज स्थापना के लिए sdist setup.py फ़ाइलों से मनमाने कोड के निष्पादन की अनुमति दी जानी चाहिए। वह कोड वास्तव में आपके होम डायरेक्टरी में आपकी सेटिंग्स की तरह चीजों को अधिलेखित कर सकता है, या चीजों को आपके पथ, या किसी भी चीज में जोड़ सकता है। इसलिए स्पष्ट रूप से pypi (एक जानकार, विश्वसनीय सूचकांक) को विशेषाधिकार देना और हैश जाँच की आवश्यकता सुरक्षा की दिशा में एक अच्छा कदम है। यह ज्ञात सुरक्षा खतरों के केंद्रीकृत नियंत्रण और उन्मूलन की अनुमति देता है और वितरित फैशन में आपके द्वारा डाउनलोड किए जा रहे पैकेजों के सत्यापन की पहचान करता है। आपके द्वारा डाउनलोड की गई लॉकफाइल हैश के बारे में क्या कहती है जो आपको मिलनी चाहिए? यह मेल नहीं खाता कि आप इंडेक्स से क्या प्राप्त कर रहे हैं? ऑपरेशन के इस मोड को विफल करने के लिए आपको स्थानीय मशीन, इंडेक्स और नेटवर्क लेयर में से एक से अधिक विफलताओं की आवश्यकता है क्योंकि आप अपने एप्लिकेशन स्टैक में कई दूषित पैकेज होने के बारे में बात कर रहे हैं जो एक विश्वसनीय इंडेक्स के खिलाफ हैश की पुष्टि करने वाले कॉन्सर्ट में काम कर रहे हैं। , और कई मामलों में हैश स्वयं एक अन्य असंबद्ध स्रोत से आया है। तो अब आपको कम से कम, पाइप और पिपेनव दोनों में हैश की जांच करने की आवश्यकता है, किसी भी तरह से छेड़छाड़ की गई है कि यह हैश उत्पन्न करता है जो आप उम्मीद कर रहे हैं, लेकिन अन्य दुर्भावनापूर्ण चीजें स्थापित करते हैं?

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

@ncoghlan @njsmith sudo pip install... के खिलाफ वापस धक्का देने के कदम के साथ यह सब कैसे कारक है और सामान्य ज्ञान मुझे लगता है कि हम सभी के पास यह है कि यदि आप पीआईपी का उपयोग करने जा रहे हैं, तो आपको शायद अपने का उपयोग नहीं करना चाहिए सिस्टम पैकेज मैनेजर पाइथन चीजों को व्यापक रूप से बोलने के लिए स्थापित करने के लिए। यह वास्तव में एक पिपेनव प्रश्न नहीं है, लेकिन यह वह जगह है जहां चर्चा अभी है और यह अगले चरणों का मार्गदर्शन कर सकती है ...

@techalchemy मुझे इस विषय से कोई संबंध नहीं दिख रहा है? मुझे लगता है कि उपरोक्त सभी का निष्कर्ष यह है कि उपयोगकर्ताओं को ओवरराइड करने देना जो PyPI के लिए पिपेनव का उपयोग करता है, कोई अतिरिक्त खतरा पेश नहीं करता है, और sudo pipenv करने से पहली जगह में भी कोई मतलब नहीं है, है ना?

@njsmith नहीं, मुझे नहीं लगता कि किसी को भी sudo pipenv का उपयोग करना चाहिए, जैसा कि मैंने उल्लेख किया है कि यह वास्तव में विषय पर नहीं है, लेकिन चूंकि हम खतरे के मॉडल पथ से थोड़ा नीचे चले गए, मैंने सोचा कि यह खोज के लायक था। विशेष रूप से:

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

यदि कम से कम कुछ क्षमता में रक्षा एक विशेषाधिकार प्राप्त स्थान पर संग्रहीत चाबियों पर निर्भर करती है, लेकिन हम विशेषाधिकार प्राप्त पायथन इंस्टॉल का उपयोग करने की सलाह दे रहे हैं, तो मुझे लगता है कि यह संभवतः चर्चा के लायक है। शायद मैं गलत हूँ। लेकिन यह निश्चित रूप से @ncoghlan की टिप्पणी से संबंधित लगता है (लेकिन sudo pipenv नहीं, यह कभी भी बात नहीं होनी चाहिए)

हाँ, शायद ऐसा लग रहा था कि यह कहीं से आया है, बस एक यादृच्छिक विचार है। उम्मीद है कि अतिरिक्त संदर्भ इसे कुछ स्पष्ट करता है

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

ठीक है, तो चलिए उस व्यवहार को परिभाषित करते हैं जिसकी हम अपेक्षा करते हैं या पसंद करते हैं। मेरी वर्तमान कामकाजी समझ यह है कि:

• अगर --pypi-mirror पास हो गया है या PIPENV_PYPI_MIRROR सेट है, तो हमें इसे पसंद करना चाहिए
• क्या हमें इसे केवल पीईपीआई पर पसंद करना चाहिए? हम यह आकलन कैसे कर रहे हैं कि दिया गया इंडेक्स यूआरएल 'पीईपीआई' है या नहीं - हम इसे क्वेरी नहीं कर सकते हैं, इसलिए हमें एक सूची बनाए रखनी होगी
• क्या सूची में सभी संभावित क्रमपरिवर्तन शामिल हैं, या क्या हमें उन दो यूआरएल का उपयोग करने के साथ संतुष्ट होना चाहिए जो हमने पिपफाइल बनाने के लिए अतीत में उपयोग किए हैं, जिनके लिए हमें पहले प्रदान किए गए दर्पण का प्रयास करना चाहिए?

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

मेरे लिए सही दृष्टिकोण की तरह लगता है।

@njsmith ने जो कहा वह मेरे दृष्टिकोण से भी मेल खाता है। प्रारंभिक पीआर में बदलने के लिए मैं 3 रेपो यूआरएल का सुझाव दूंगा:

• कोई नहीं सेट (यानी जब pip की डिफ़ॉल्ट सेटिंग पर निर्भर हो)
• https://pypi.python.org/simple
• https://pypi.org/simple

यूआरएल को अलग-अलग सूचीबद्ध करने के बजाय ट्रेलिंग-स्लैश-या-नॉट को यूआरएल सामान्यीकरण चरण के रूप में बेहतर तरीके से संभाला जा सकता है।

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

ठीक है, मेरा विचार था:

• बिना पीछे वाले स्लैश के URL की सूची बनाए रखें
• एक अनुगामी स्लैश के लिए आने वाले URL की जाँच करें, और यदि मिल जाए तो इसे हटा दें ( str.rstrip संभवतः कार्य के लिए पर्याप्त होगा, भले ही यह अनुगामी स्लैश की एक मनमानी संख्या को हटा देगा, अन्यथा हम इसके बारे में सख्त हो सकते हैं, और अधिक से अधिक एक अनुगामी स्लैश हटा दें)

विस्मयकारी। मुझे लगता है कि यह काम करने के लिए पर्याप्त है और निर्माण के लिए काफी आसान है। सबको शुक्रीया!

आशा है कि मिरर फीचर जल्द ही जोड़ा जा सकता है~

मैं भी इस मुद्दे का सामना कर रहा हूं। स्थिति यह है:

• कुछ निजी पैकेजों के साथ एक आंतरिक पीपीपीआई सर्वर रखें।
• कई पायथन एप्लिकेशन हैं जो अपनी निर्भरता को प्रबंधित करने के लिए पिपेनव का उपयोग करते हैं।
• कुछ निर्भरताएँ आंतरिक PyPI सर्वर पर रहती हैं, और अन्य समुदाय PyPI पर। आंतरिक कोई भी पैकेज नहीं मिलने के लिए समुदाय PyPI पर पुनर्निर्देशित करता है।

मेरी परिनियोजन रणनीति पहले से ही एक सिस्टम-व्यापी pip.conf सेट करती है जो आंतरिक PyPI सर्वर को संदर्भित करता है। आश्चर्यजनक रूप से, मैंने पाया कि पिपेनव द्वारा इस कॉन्फ़िगरेशन को अनदेखा किया गया है।

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

इस एक बीटीडब्ल्यू पर पीआर का स्वागत है

नमस्ते। मुझे वही ज़रूरत है लेकिन मैं इस ओवरराइड सुविधा को दूसरे टिकट में विभाजित कर दूंगा।

मेरा अपेक्षित व्यवहार प्रस्ताव यहां दिया गया है:

• Pipfile के [[स्रोत]] खंड में परिभाषित प्रत्येक मान को सेट करने के लिए एक कॉन्फ़िगरेशन फ़ाइल को परिभाषित किया जा सकता है।
• पिपफाइल के केवल [[स्रोत]] खंड के साथ एक टॉमल फ़ाइल हो सकती है
• इस फ़ाइल का स्थान pip.conf (उदा: /etc/pipenrc.toml, ~/.pipenvrc.toml) के लिए परिभाषित नियमों से अत्यधिक प्रेरित है।
• इन मूल्यों को ओवरराइड करने के लिए पर्यावरण चर को भी परिभाषित किया जा सकता है (अनुस्मारक: हमें [[स्रोत]] के सभी मूल्यों की आवश्यकता है)। परिभाषित किया जाना
• पिपेनव का वर्तमान व्यवहार अब है:
  
  
  
  • पिपफाइल बनाते समय, यह कॉन्फ़िगरेशन फ़ाइल / पर्यावरण चर से मान लेता है
  
  
  • यदि कोई कॉन्फ़िगरेशन फ़ाइल या पर्यावरण चर परिभाषित नहीं है, तो पिपेनव का वर्तमान व्यवहार लागू होता है
  
  
  • पिपेनव हमेशा पिपफाइल के [[स्रोत]] खंड को उत्पन्न करना जारी रखता है
  
  
  • यदि पिपफाइल का एक [[स्रोत]] खंड मौजूद है, तो पिपेनव कॉन्फ़िगरेशन फ़ाइल के मानों के साथ किसी भी चीज़ को ओवरराइड करने का प्रयास नहीं करता है।
  
  

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

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

शायद मुझे कुछ याद आया, लेकिन यह एक प्रतिगमन की तरह लगता है। हम कुछ समय के लिए 11.6.0 पर रहे हैं, और pipenv खुशी-खुशी हमारे pip.conf में सेटिंग्स को सौंप दिया गया है, जो एक आंतरिक pypi दर्पण की ओर इशारा करता है।

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

स्पष्ट होने के लिए: 2018.05.18 में अपग्रेड करने के बाद, यहां तक ​​​​कि हमारे पिपफाइल [.लॉक] में निर्दिष्ट दर्पण के साथ, पिपेनव pypi.org से नए पैकेज स्थापित करने का प्रयास करता है।

हो सकता है कि मैं जो देख रहा हूं वह इससे अलग मुद्दा है ...

@brettdh आपके पर्यावरण को देखे बिना बताना मुश्किल है, लेकिन मुझे लगता है कि यह वही मुद्दा नहीं है। मेरा सुझाव है कि आप रिलीज के बीच कुछ द्विभाजित करके देखें कि यह वास्तव में कहां बदल गया है, और इसके लिए एक नया मुद्दा खोलें।

मैं इसके लिए पीआर पर काम कर रहा हूं।

मुझे लगता है कि यह डिफ़ॉल्ट सेटिंग के साथ वापस आ गया था। यह पाइप 10 के लिए अद्यतनों की एक लहर में पकड़ा गया हो सकता है जो अभी तक जारी नहीं किया गया है, लेकिन मेरा मानना ​​​​है कि हम इसे बहुत अधिक कठिनाई के बिना उठा सकते हैं यदि @JacobHenner इसे पहले से नहीं जोड़ रहा है

मुझे लगता है कि आप आधिकारिक पीपीपीआई के लिए देवपी को कैशिंग प्रॉक्सी के रूप में उपयोग करने के बारे में बात कर रहे हैं। पाइप के लिए, आपको सभी अनुरोधों के लिए अपने स्थानीय देवपी सर्वर का उपयोग करने के लिए पाइप के लिए /etc/pip.conf और /usr/lib64/python3.6/disutils/distutils.cfg को संशोधित करने की आवश्यकता होगी।

हालांकि, ऐसा लगता है कि pipenv इन सिस्टम-वाइड सेटिंग्स को अनदेखा करता है, इसलिए आपको अपने devpi सर्वर को संदर्भित करने के लिए Pipfile में [[source]] कॉन्फ़िगरेशन सेटिंग को संशोधित करने के लिए मजबूर होना पड़ता है। लेकिन फिर यदि आप अपने पिपफाइल को बाहरी रूप से प्रकाशित करते हैं, तो बाहरी योगदानकर्ताओं को वास्तव में अपना वातावरण बनाने के लिए आपकी [[source]] सेटिंग्स को हटाना होगा।

मुझे लगता है कि पिपेनव को केवल /etc/pip.conf और /usr/lib.../distutils.cfg से वैश्विक सेटिंग्स का सम्मान करना चाहिए

@ पोल्स्की-जी

मुझे लगता है कि आप आधिकारिक PyPi के लिए देवपी को कैशिंग प्रॉक्सी के रूप में उपयोग करने के बारे में बात कर रहे हैं

नेक्सस रिपोजिटरी, लेकिन हाँ, वही विचार।

हालाँकि, ऐसा लगता है कि pipenv इन सिस्टम-वाइड सेटिंग्स को अनदेखा करता है

जैसा कि @techalchemy ने उल्लेख किया है, मेरा मानना ​​​​है कि पिपेनव (11.6.0) pip.conf (होमडिर भी) का सम्मान करता था, लेकिन नवीनतम संस्करण नहीं करता है - विशेष रूप से, कहीं हार्ड-कोडेड pypi.org यूआरएल है (निर्भरता संकल्प, आईआईआरसी) जिसे ओवरराइड नहीं किया जा सकता है।

मुझे लगता है कि pipenv को /etc/pip.conf और /usr/lib.../distutils.cfg से वैश्विक सेटिंग्स का सम्मान करना चाहिए

सहमत - हालांकि व्यक्तिगत रूप से मुझे अपने उपयोग के मामले में distutils.cfg को संशोधित नहीं करना पड़ा।

IIRC में pip.conf का सम्मान नहीं करने का एक संकल्प था, लेकिन इसे खोजने के लिए आपको समस्या ट्रैकर में गहराई से खुदाई करने की आवश्यकता होगी। किसी भी मामले में, जहाज रवाना हो गया है, और पीईपीआई मिररिंग लगभग पूरा होने के साथ, निकट भविष्य में इसके बदलने की संभावना नहीं है।

मुझे पूरा विश्वास है कि यह सुविधा अगली रिलीज़ में शिप होगी (जो अगले एक या दो दिनों में भाग्य के साथ शिप हो जाएगी)

इसके अलावा, मैं इसके बारे में निश्चित नहीं हूं, लेकिन यह संभव है कि कॉन्फ़िगरेशन डिफ़ॉल्ट प्राप्त करने के लिए यहां कॉन्फ़िगरेशन पार्सर बनाने के बाद हमें .load() पर कॉल करने की आवश्यकता हो सकती है

https://github.com/pypa/pipenv/blob/master/pipenv/project.py#L573 -#L577

@uranusjr जब तक मिररिंग कॉन्फ़िगरेशन काम करता है (यानी उस हार्डकोडेड pypi.org यूआरएल का मैंने उल्लेख नहीं किया है), मुझे पिपेनव के साथ अपनी कॉन्फ़िगरेशन रखने और पीआईपी की अनदेखी करने में कोई समस्या नहीं दिख रही है।

@brettdh क्या आप मेरी शाखा चेकआउट कर पाएंगे और पुष्टि करेंगे कि यह आपकी शाखा से मिलती है
अपने पर्यावरण में केस का प्रयोग करें?

>

@JacobHenner हाँ, धन्यवाद। --pypi-mirror विकल्प ( pipenv install , pipenv lock ) के साथ मेरा प्रारंभिक परीक्षण ऐसा लगता है कि यह ठीक काम करता है। मैंने जनसंपर्क पर एक छोटा सा सुझाव छोड़ा है।

मैं थोड़ा चिंतित हूं, हालांकि, pypi.org पर हार्डकोड किए गए यूआरएल अभी भी पाइपनव स्रोतों में बिखरे हुए दिखाई देते हैं। मैं यह सुनिश्चित नहीं कर सकता कि [[source]] प्रविष्टियों से कौन-से सही ढंग से ओवरराइड किए गए हैं, और मुझे ठीक से याद नहीं है कि किस वर्कफ़्लो के कारण मेरी समस्या ऊपर आई है। इसलिए यह बताना मुश्किल है कि क्या यह तय है। मैं

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

हाल ही के संस्करण को खींचा और यह अभी भी स्रोतों में pypi.org को हार्डकोड कर रहा है। क्या लक्ष्य पर्यावरण चर या पीपीआई-दर्पण लेना है और इसे [[स्रोत]] के लिए डिफ़ॉल्ट के रूप में रखना है?

संपादित करें:

बस कोड के माध्यम से खोदा गया .. ऐसा लगता है कि आपके पास है

if PIPENV_TEST_INDEX:
    DEFAULT_SOURCE = {
        u"url": PIPENV_TEST_INDEX,
        u"verify_ssl": True,
        u"name": u"custom",
    }
else:
    DEFAULT_SOURCE = {
        u"url": u"https://pypi.org/simple",
        u"verify_ssl": True,
        u"name": u"pypi",
    }

मुझे लगता है कि यदि आपने PIPENV_TEST_INDEX को पर्यावरण चर PIPENV_PYPI_MIRROR में बदल दिया है तो यह एक अच्छी शुरुआत होगी

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

नहीं, पिपफाइल में स्रोत नहीं बदलना चाहिए। इस बदलाव का लक्ष्य
उपयोगकर्ताओं को एक दर्पण के साथ PyPI URL को ओवरराइड करने की अनुमति देना था, _बिना_बदलते
पिपफाइल।

@JacobHenner मिरर हैंडलिंग कोड स्रोत सूची को पोस्टप्रोसेस करता है और निर्दिष्ट दर्पण के संदर्भ में pypi.org URL को बदल देता है।

यही कारण है कि $#$ Pipfile में एक स्पष्ट pypi.org प्रविष्टि होने पर भी दर्पण ओवरराइड को काम करने देता है। pipenv फिर अपने स्वयं के डिफ़ॉल्ट स्रोत को ओवरराइड करने के लिए उसी तर्क पर निर्भर करता है।

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

मुझे लगता है कि आखिरी टिप्पणी @kylecribbs के लिए थी?

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