एक महत्वाकांक्षी प्रस्ताव!

ini कॉन्फ़िगरेशन समर्थन (उपयोगकर्ताओं के घर में मौजूद एक वैश्विक आईएनआई कॉन्फ़िगरेशन)

प्लेटफ़ॉर्म-पसंदीदा स्थानों में कॉन्फ़िगरेशन खोजने के लिए एपडीर (या समान) का उपयोग करने पर विचार करें।

appdirs अच्छी तरह से एक विकल्प हो सकता है, हालांकि तब हमें अपने पैकेज में सामान बेचने का व्यवसाय शुरू करना होगा। निष्पक्ष होने के लिए इसमें से 70% पहले ही किया जा चुका है, बस एक बेहतर पुनर्गठन की आवश्यकता होगी।

केवल इस पर निर्भर रहने के बजाय विक्रेता क्यों? (ऐसा नहीं है कि यह विक्रेता के लिए कठिन है, यह केवल एक फ़ाइल है)। IMO, हमें वास्तव में यह स्वीकार करने की आवश्यकता है कि (पाइप के उल्लेखनीय अपवाद के साथ) पैकेजिंग उपकरण वास्तव में किसी भी अन्य एप्लिकेशन की तरह ही बनाए जाने चाहिए। यदि निर्भरता होना पर्याप्त रूप से कठिन है कि PyPA ऐप्स उनसे बचते हैं, तो इसका क्या मतलब है कि हम अपने उपयोगकर्ताओं के लिए एप्लिकेशन विकसित करना कितना आसान बना रहे हैं?

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

मुझे लगता है कि क्रॉस दुभाषिया सुविधा को बेचने के बिना कठिन होगा। उदाहरण के लिए वर्चुअलएन्व स्थापित नहीं होने वाले दुभाषिया के लिए वर्चुअल वातावरण बनाना।

PYTHONPATH=/t/path/to/virtualenv.whl python -m virtualenv

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

@gaborbernat आपका मतलब -p विकल्प से है? मुझे ऐसा लगता हैं। ऐसा लगता है कि ठीक उसी तरह की स्थिति है जिसमें zipapps को मदद करने का इरादा था, लेकिन किसी ने भी वास्तव में इसे अच्छी तरह से काम करने के विवरण को खत्म करने के लिए बहुत कुछ नहीं किया है।

@pradyunsg से :

उह, इसका मतलब यह होगा कि हम virtualenv के किसी भी अतिरिक्त पैकेज पर निर्भर नहीं रह सकते हैं

वास्तव में, के रूप में @gaborbernat कहा, -p विकल्प शायद का तात्पर्य है कि :-( लेकिन मैं आश्चर्य कर कारण है कि हम "पर पहिया जरूरत PYTHONPATH के साथ ही विकल्प" zipapp - विशेष रूप से पहियों कि दिए गए PYTHONPATH पर सामान्य रूप से असमर्थित हैं (हम उन्हें वर्चुअलएन्व के भीतर आंतरिक रूप से सामान्य पाइप बूटस्ट्रैपिंग कारणों के कारण उपयोग करते हैं - पीआईपी सब कुछ के लिए बहुत अधिक अपवाद है ;-))

समर्थन की दो साल की छूट अवधि

हम्म...

यहां मेरी चिंता यह है कि इसके नेटवर्क प्रभाव से पायथन के नए संस्करणों को अपनाने की गति धीमी हो सकती है और समर्थित पायथन की संख्या का संयोजन विस्फोट हो सकता है। CPython 3.9 के लिए अलग-अलग रिलीज़ ताल पर चर्चा कर रहा है, इसलिए 2 साल और भी अधिक हो सकते हैं जो कुछ रिलीज़ कोर डेवलपर्स से हो सकते हैं।

उस ने कहा, मैं इसे अवरुद्ध नहीं करना चाहता, लेकिन ज्यादातर यह सुनिश्चित कर रहा हूं कि मैं आवाज उठाऊं कि मैं ऐसा करने का इच्छुक नहीं हूं।

(किसी बिंदु पर आयरनपीथन और ज्योथन की उम्मीद - किसी अन्य को हमें समर्थन देना चाहिए?)

निश्चित रूप से। @gaborbernat शायद जानता है कि मैं यह कहूंगा - ये अच्छा होगा लेकिन मुझे पूरा यकीन है कि जो लोग कार्यान्वयन से अधिक परिचित हैं वे ऐसा करने के लिए सबसे अच्छी स्थिति में होंगे। कम से कम, लंबी अवधि में समर्थन के मामले में, और आदर्श रूप से, इसे पहले स्थान पर अच्छी तरह से समर्थित करने का काम (सीआई, परीक्षण, आदि)।

सबसे पहले, आईएनआई कॉन्फ़िगरेशन समर्थन (उपयोगकर्ताओं के घर में मौजूद एक वैश्विक आईएनआई कॉन्फ़िगरेशन),

मैं पक्षपाती हूं - मैं वास्तव में इसे इसके बजाय TOML देखना चाहता हूं। :)

(मैंने अभी तक इसे पूरी तरह से संसाधित नहीं किया है क्योंकि मुझे कहीं जाना है - लेकिन यह एक महान समग्र लक्ष्य की तरह दिखता है!)

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

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

मुझे यकीन नहीं है कि मैं इसके लिए तर्क को समझता हूं। ऐसा लगता है कि यह virtualenv के रखरखाव को कठिन बना देगा और यह अंतिम उपयोगकर्ताओं के लिए व्यवहार को समझना कठिन बना देगा। setuptools पहले से ही बंदर पैच जारी रखने के बजाय distutils को अवशोषित करने की कोशिश करके दूसरी तरफ जा रहा है।

@pganssle स्कोप अलग है और प्रॉब्लम स्पेस भी। virtualenv समस्या यह है कि अक्सर सिस्टम सिस्टम पैकेज पर अतिरिक्त बाधाएं डालता है, इसलिए वे बंदर इन का पालन करने के लिए अंतर्निहित वेनव को पैच करते हैं। इन सभी को दोहराना कठिन होगा, उदाहरण के लिए #1362 देखें।

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

वर्चुअलएन्व को भी कुछ भी बंद करने की आवश्यकता नहीं होगी, यह केवल सार्वजनिक एपीआई का उपयोग करेगा जो ठीक होना चाहिए।

एफडब्ल्यूआईडब्ल्यू मैं अपनी पुरानी पुनर्लेखन वर्चुअलएन्व शाखा की जांच करने की अनुशंसा करता हूं, इसने पहले से ही इनमें से बहुत सी चीजें की हैं।

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

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

697 -- @dstufft का पुराना PR

PYTHONPATH=/t/path/to/virtualenv.whl python -m virtualenv

ओटीओएच, हमें शायद ऐसा नहीं करना चाहिए - https://www.python.org/dev/peps/pep-0427/#is -it-possible-to-import-python-code-directly-from- एक पहिया फ़ाइल

@pradyunsg तो पथ पर पहिया लगाए बिना पाइप को बूटस्ट्रैप करने के लिए कोई अन्य तरीका?

बूटस्ट्रैपिंग पाइप शायद ठीक है - वर्चुअलएन्व अब ¹ का उपयोग करता है। लेकिन मैं दृढ़ता से केवल इसे पीआईपी के लिए उपयोग करने की अनुशंसा करता हूं, न कि वर्चुअलएन्व चलाने के साधन के रूप में।

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

किसी भी कारण से हम पाइप को zipapp रूप में शिप नहीं करते हैं? जैसा कि मैं समझता हूं, इस आवश्यकता से बचना होगा, और zipapp को अजगर 2.7 के साथ समर्थित किया गया है

@gaborbernat क्या आपने कोशिश की है? क्या यह काम करता है? यदि आपके द्वारा उल्लिखित दृष्टिकोण विंडोज़ पर काम करता है तो मुझे कोई प्रारंभिक चिंता नहीं है लेकिन @uranusjr की प्रतिक्रिया होगी। मेरी केवल टिप्पणियां @dstuff के अनुरूप हैं जो कहना है - सरल बेहतर है

किसी भी कारण से हम ज़िप को ज़िप के रूप में क्यों नहीं भेजते?

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

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

हमेशा की तरह, ऐसा नहीं होने के मुख्य कारण हैं:

1. यह किसी ने नहीं सोचा।
2. इसे करने के लिए किसी के पास समय/प्रेरणा नहीं थी।
3. वर्तमान दृष्टिकोण ठीक काम करता है, और तलने के लिए बड़ी मछलियाँ हैं।

तो पथ पर पहिया लगाए बिना पाइप बूटस्ट्रैपिंग के लिए कोई अन्य तरीका?

मुझे नहीं लगता कि हमें यहां इसकी आवश्यकता है - वर्चुअलएन्व स्वयं आईआईआरसी से स्थापित करने के लिए पाइप व्हील का उपयोग कर रहा है, जिसे ठीक काम करना चाहिए। जैसा कि @pfmoore ने कहा, केवल "अतिरिक्त" चीज जो get-pip.py करती है वह है प्रमाणपत्रों को अनपैक करना और उन्हें एक पथ प्रदान करना। चूंकि वर्चुअलएन्व का उपयोगकेस नेटवर्क पर नहीं आएगा, इसलिए हमें यहां कुछ भी नया करने की आवश्यकता नहीं है।

वर्तमान दृष्टिकोण ठीक काम करता है, और तलने के लिए बड़ी मछलियाँ हैं।

यह, अन्य IMO की तुलना में बहुत अधिक है। हम कर सकते थे लेकिन निपटने के लिए और अधिक प्रभावशाली मुद्दे हैं। :)

मेरे पास एक बिंदु पर एक पीआर था जिसने एक ज़िप ऐप के रूप में पाइप बनाया, यह काम किया लेकिन आईआईआरसी मुझे इसे पूरी तरह कार्यात्मक बनाने के लिए पाइप में बदलाव करना पड़ा।

यह अब थोड़ा जटिल हो सकता है क्योंकि पीईपी 517 के लिए पीआईपी खुद को एक उपप्रक्रिया के रूप में आमंत्रित करता है। मुझे यकीन नहीं है लेकिन यह निश्चित रूप से तलाशने लायक है।

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

सभी बड़ी मछलियों को फ्राई करने के बाद वैकल्पिक पिप बूटस्ट्रैपिंग का पता लगाया जा सकता है

एक योजना की तरह लगता है [जिसका हम पहले से ही अनुसरण कर रहे हैं। ;)]

लिंक के लिए धन्यवाद, फीडबैक के आधार पर मैंने https://github.com/gaborbernat/virtualenv/tree/rewrite/src/virtualenv पर कुछ प्रारंभिक कार्य शुरू कर दिया है 20.0.0 ।

वेनव का उपयोग करने के लिए +1 यदि यह मौजूद है। यह पीपीपी के उपयोग के मामले को आसान बना देगा।

इसलिए पुनर्लेखन एक ऐसी स्थिति में आ गया, जहां मैं सहज महसूस करता हूं कि लोग इसे देख रहे हैं और कुछ प्रतिक्रिया दे रहे हैं। अगर आपके पास इसमें मदद करने के लिए कुछ खाली समय है तो कृपया मुझसे संपर्क करें; योजना इसे महीने के अंत तक जारी करने की है नोट https://github.com/pypa/virtualenv/milestone/7 अभी भी लागू करने की आवश्यकता है, हालांकि, मूल विचार है।

पुनश्च. https://github.com/pypa/virtualenv/pull/1481/ के तहत एक फीडबैक पीआर बनाया

फ़ीचर अनुरोध: कस्टम पर्यावरण चर को परिभाषित करने के लिए एक तंत्र प्रदान करें, उदाहरण के लिए मानक प्रारूप के साथ venv बिन निर्देशिका में env.txt फ़ाइल रखकर:

VARNAME=value
OTHERVAR=othervalue

मुझे नहीं लगता कि मैं आपके उपयोग के मामले को समझता हूं? इन पर्यावरण चर का उपयोग कैसे किया जाएगा, सेट किया जाएगा, कब?

संपादित करें। एनएम. मैं देख रहा हूं कि आपने https://github.com/pypa/virtualenv/issues/1124 पर विस्तार किया है

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

रोलआउट के संदर्भ में हमारी क्या योजना है? क्या हमारे पास मुख्य रिलीज़ से पहले बीटा रिलीज़ होगा?

हाँ, सोमवार को कुछ प्राप्त करना चाहते हैं... और फिर प्रतिक्रिया के लिए एक सप्ताह के लिए अस्थायी रूप से छोड़ दें, सुधार करें... और फिर मास्टर को पुनर्लेखन और रिलीज़ के साथ बदलें।

मुझे 100% यकीन नहीं है कि एक सप्ताह पर्याप्त होगा और हमें निश्चित रूप से कई चैनलों पर संवाद करना चाहिए कि हम चाहते हैं कि लोग बीटा को आज़माएं।

वहाँ खोजशब्द अस्थायी रूप से था । मैं यहां आशावादी हूं, मैंने जितना प्रयास किया है, उसे देखते हुए मैं प्रमुख मुद्दों की उम्मीद नहीं कर रहा हूं, लेकिन ‍♂

वर्चुअलएन्व 20.0.0 बीटा1 उपलब्ध है ।

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