<p>पाइप 19.1 और विकास मोड (pyproject.toml के साथ - बिल्ड-बैकएंड मौजूद)</p>

जबकि मैं यहां दोष को विभाजित करने की कोशिश नहीं कर रहा हूं, यह ध्यान दिया जाना चाहिए कि pyproject.toml हटाना बहुत आसान फिक्स होगा। ऐसा संभव नहीं होने का कारण यह प्रतीत होता है क्योंकि black जैसी परियोजनाओं ने अपने सामान्य कॉन्फ़िगरेशन के लिए उस फ़ाइल का उपयोग करना चुना, जिसे पीईपी 518 द्वारा तर्कसंगत रूप से अनुमति दी गई है (यह इस बात पर निर्भर करता है कि आप "बिल्ड टूल" को मूल रूप से कैसे परिभाषित करते हैं) लेकिन थोड़ा समयपूर्व माना जा सकता है, जब उस फ़ाइल का इच्छित उपयोग (पीईपी 517 और 518 अभी भी विकास में थे)।

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

@pfmoore यह महत्वपूर्ण नहीं है कि हम यहां कैसे पहुंचे या किसे दोष देना है।

इससे जो कार्यप्रवाह टूटता है वह निम्नलिखित है: आप अपना कोड PEP-517/518 के रूप में वितरित करना चाहते हैं। और आप अपने सीआई/टॉक्स में शुद्ध पीईपी-517/518 के साथ परीक्षण कर रहे हैं। हालांकि, कोडबेस विकसित करते समय कोड को डेवलपर मोड में स्थापित करना सहायक होता है (आपके परीक्षण चलाने के लिए प्रत्येक कोड-परिवर्तन के बाद पैकेज को पुनर्स्थापित करने की आवश्यकता से बचने के लिए)। ऐसे मामले में, आप कोड को संपादन योग्य मोड में स्थापित करना चाहते हैं (लेकिन pyprojec.toml को रखने के लिए भी)। इस मामले में फ़ाइल को हटाना संभव नहीं है। नो पेप 517 बिल्ड निर्दिष्ट करना भी काम नहीं करता है।

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

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

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

@pfmoore हालांकि ठीक है, संपादन योग्य मोड हमेशा एक करीब पर्याप्त सन्निकटन था; गैर-संपादन योग्य परीक्षण सूट वे हैं जो पुष्टि करते हैं कि 100% कोड अच्छा है। उदाहरण के लिए, यदि कोई संसाधन लोड करेगा तो वे अलग तरह से व्यवहार कर सकते हैं। लेकिन यह मामला पहले से ही है। जैसे कि कुछ झंडों को पारित करने की आवश्यकता ठीक है, हालांकि, अभी के लिए, ऐसा करने का कोई तरीका नहीं है। क्या हमें कोई फिक्स मिल सकता है? --really-ignore-pep517-for-develop-mode मेरे द्वारा ठीक है।

नो पेप 517 निर्दिष्ट करना मेरे लिए काम नहीं किया। टॉक्स का उपयोग करते समय इसे हिट करने वाले किसी भी व्यक्ति के लिए, एक कस्टम install_command लाइन को tox.ini में जोड़ना मेरा वर्तमान वर्कअराउंड है (मेरे पास केवल pyproject.toml है जो लाइन की लंबाई को काले रंग में सेट करने के लिए है)।

[testenv]
install_command =
    python -m pip install --no-use-pep517 {opts} {packages}

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

@gaborbernat क्या आप कुछ ऐसा कर सकते हैं जैसे आपके पास एक साधारण रैपर स्क्रिप्ट है जिसका उपयोग आप स्थानीय रूप से विकसित करते समय करते हैं जो संपादन योग्य मोड में स्थापित करने से पहले फ़ाइल को स्थानांतरित करता है? या सीआई, आदि में चलते समय pyproject.toml फ़ाइल की प्रतिलिपि बनाना? मुझे सटीक स्थिति के बारे में निश्चित नहीं है, लेकिन ऐसा लगता है कि वर्कफ़्लो के साथ आने में आपके पास उचित मात्रा में लचीलापन होगा।

फाइलों के इर्द-गिर्द घूमना वास्तव में एक बुरा समाधान है और इससे बहुत अधिक परेशानी होगी। यह अब उदाहरण के लिए टॉक्स तोड़ता है। tox यह अब एक विकसित वातावरण बनाने में सक्षम नहीं है।

pyproject.toml को बाहर और पीछे ले जाने से समस्या हल हो जाएगी (एक भयानक भयानक तरीके से), यह समानांतर मोड को तोड़ देगा। कल्पना कीजिए कि यदि आप समानांतर में 5 टॉक्स वातावरण चलाना चाहते हैं, तो उनमें से 4 पीईपी 517/518 का उपयोग करते हैं और कोई एक संपादन योग्य संस्थापन चाहता है (उदाहरण के लिए साइथन कोड कवरेज का एकमात्र तरीका है)। मुझे फिर से एक बुरी जगह की तरह महसूस होता है, अब किसी को कुछ लॉक की आवश्यकता होगी ताकि काम के पेड़ को क्यों बदला जा सके, बस एक संपादन योग्य इंस्टॉल प्राप्त करने के लिए। इस बिंदु पर, मैं या तो पाइप <19.1 पर डाउनग्रेड करता हूं, या python setup.py develop उपयोग करता हूं ... मैं वास्तव में एक अस्पष्ट ध्वज के पीछे एक वास्तविक पीईपी -517/पीईपी -518 अक्षम करना पसंद करूंगा। स्रोत निर्देशिका को जगह में बदलने के बजाय, उस बिंदु पर रैपर स्क्रिप्ट उस से गुजर सकती है।

कल्पना कीजिए कि यदि आप समानांतर में 5 टॉक्स वातावरण चलाना चाहते हैं, तो उनमें से 4 पीईपी 517/518 का उपयोग करते हैं और एक संपादन योग्य इंस्टालेशन चाहता है

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

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

खैर, मैंने कभी नहीं कहा कि मैं मैन्युअल रूप से install in develop mode when developing locally हूं (मैं उसके लिए भी टॉक्स का उपयोग करता हूं) या उसी रेपो पर किसी अन्य ऑपरेशन के समानांतर नहीं। इस समय पाइप इंस्टाल समानांतर सुरक्षित हैं, आपका सुझाव उस स्थिरांक को तोड़ देगा, इसलिए यह एक सच्चा समाधान नहीं है।

क्या हमें कोई फिक्स मिल सकता है?

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

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

लेकिन हाँ, हम नियत समय में एक सुधार प्राप्त कर सकते हैं।

पुनश्च यह वास्तव में संभव हो सकता है कि पीईपी 517 एक्सटेंशन समर्थन संपादन योग्य मोड को पिप की अगली रिलीज से पहले 3 महीने में क्रमबद्ध किया जाए - आइए अस्थायी समाधानों पर यहां सारी ऊर्जा बर्बाद न करें यदि हम अंतर्निहित समस्या को हल करने के लिए इसका उपयोग कर सकते हैं!

एक अन्य प्रश्न - क्या यह पिप 19.1 में कुछ नया है? PEP 517 सपोर्ट कुछ महीने पहले 19.0 में पेश किया गया था - क्या 19.1 में कुछ ऐसा है जो इसे बदतर बना देता है? यदि नहीं, तो यह मामला अब अचानक से कैसे भड़क गया है? महज संयोग?

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

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

जब pyproject.toml मौजूद था, तब pip 19.0.0 ने विकास मोड (आवश्यक अनुभाग को संतुष्ट किए बिना) की अनुमति दी। पाइप 19.1 https://github.com/pypa/pip/pull/6370 के माध्यम से इसके बजाय कठिन त्रुटि का निर्णय लिया।

तो #6370 --no-use-pep517 का उपयोग करने के लिए कहता है। क्या आप कह रहे हैं कि पीआर टूट गया है, और यह नहीं है (जैसा कि कहा गया है) "पीईपी 517-इस-वैकल्पिक मामले के लिए फिर से काम कर रहा है (बशर्ते --no-use-pep517 पारित किया गया था)"?

यदि पीआर वह वितरित नहीं कर रहा है जो वह वितरित करने का दावा करता है, तो आइए इसे ठीक करें (और हां, ऐसा सुधार 19.1.1 रिलीज की गारंटी दे सकता है), अभी और विकल्प और वर्कअराउंड न जोड़ें। लेकिन हमें उस मामले में टूट-फूट को पुन: उत्पन्न करने के निर्देशों की आवश्यकता होगी।

देखें https://github.com/pypa/pip/pull/6370#issuecomment -486156720

लोगों के लिए सबसे आसान काम है --no-use-pep517 को किसी भी आमंत्रण में जोड़ना जिसके लिए संपादन योग्य मोड की आवश्यकता है (जो मुझे लगता है कि आपके द्वारा देखे जा रहे किसी भी त्रुटि संदेश को कहना चाहिए)

इसके साथ विफल रहता है:

ERROR: Disabling PEP 517 processing is invalid: project specifies a build backend of setuptools.build_meta in pyproject.toml

ऐसा लगता है कि PIP ने PEP 517 से ऑप्ट-आउट करने से इंकार कर दिया है, यदि build-backend में pyproject.toml भले ही पर्यावरण सीधे setup.py चलाने की अनुमति देता हो।

@pfmoore यह मुद्दा दो पीआर में से पहले के बारे में है: https://github.com/pypa/pip/pull/6331 दूसरे के बजाय।

पहला मामला है जहां पीईपी 517 अनिवार्य है कि pyproject.toml -स्टाइल का उपयोग किया जाए और इसलिए --no-use-pep517 की अनुमति नहीं है।

मुझे लगता है कि पीईपी -517/518 संपादन योग्य इंस्टॉल (उद्देश्य पर, टीबीडी) को कवर/हैंडल नहीं करता है, इसलिए संपादन योग्य इंस्टॉल पूछने के बाद वास्तव में कुछ भी अनिवार्य नहीं है। लेकिन बहुत कम से कम हमें संपादन योग्य इंस्टॉल के मामले में पूरी तरह से PEP-517 को अक्षम करने में सक्षम होना चाहिए।

@pfmoore यहां

• https://github.com/pypa/pip/issues/6314#issuecomment -469176276

• https://github.com/pypa/pip/pull/6331#issuecomment -473231822

@cjerdonek धन्यवाद। यह अभी भी सही लगता है - पीईपी 517 संपादन योग्य मोड का समर्थन नहीं करता है, इसलिए परियोजनाओं को इसका उपयोग नहीं करना चाहिए यदि वे संपादन योग्य मोड का समर्थन करना चाहते हैं।

यह किसी पीईपी 517. के तहत संपादन योग्य मोड के लिए मानकीकरण की प्रक्रिया को फिर से खोलने के लिए और जब इस बात पर सहमति हो गया है, पिप (बेशक) यह पालन करेंगे के लिए की जरूरत पर जोर है।

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

हालाँकि, आगे बढ़ते हुए, हमें यह तय करने की ज़रूरत है कि आगे क्या करना है।

@pfmoore इस बीच हम संपादन योग्य इंस्टॉल पर सहमत हैं क्या हम अभी भी विरासत संपादन योग्य इंस्टॉल मोड (कुछ अजीब ध्वज के पीछे) की पेशकश करने की योजना बना रहे हैं या पाइप 19.0.0 ने अभी के लिए संपादन योग्य इंस्टॉल समर्थन छोड़ दिया है, और केवल संयोग से पूर्व 19.1 काम किया है?

मैं सहमत नहीं हूं कि यह एक अच्छा तरीका है। मूल रूप से, आप कह रहे हैं कि जो कोई भी विकास के लिए संपादन योग्य इंस्टॉल का उपयोग करना चाहता है उसे तैनाती के लिए pyproject.toml PEP-517/518 को भी छोड़ना होगा।

@gaborbernat इन प्रश्नों को पूछते समय, स्पष्टता के लिए आपको दो मामलों के बीच अंतर करना चाहिए कि "बिल्ड-बैकएंड" pyproject.toml या नहीं क्योंकि उत्तर दो मामलों में अलग है। यदि आप भेद नहीं करते हैं, तो यह भ्रम पैदा कर सकता है क्योंकि लोगों को पता नहीं चलेगा कि किस मामले का उल्लेख किया जा रहा है।

कार्यक्षेत्र को दर्शाने के लिए समस्या का नाम बदला।

मैंने पैकेजिंग मिनी-शिखर सम्मेलन में इस पर चर्चा करने का प्रस्ताव रखा है , इस हद तक कि "पसंद" को वोट माना जाता है, इसे पसंद करने से इसे प्राथमिकता देने में मदद मिलेगी।

किसी भी तरह से, हो सकता है कि हम अगले सप्ताह PyCon में नया मानक कूद-शुरू कर सकें? मैं सोच रहा हूँ कि रुचि रखने वाले लोगों के बीच विचारों को व्यक्त करने के लिए एक खुला स्थान अच्छा होगा, यदि समय हो तो।

अब जब समस्या का नाम दायरा निर्धारित करता है, तो मैं फिर से पूछूंगा:

इस बीच हम संपादन योग्य इंस्टॉल पर सहमत हैं क्या हम अभी भी विरासती संपादन योग्य इंस्टॉल मोड (कुछ अजीब ध्वज के पीछे) की पेशकश करने की योजना बना रहे हैं या पाइप 19.0.0 ने अभी के लिए संपादन योग्य इंस्टॉल समर्थन को छोड़ दिया है, और केवल संयोग से 19.1 से पहले काम किया है?

मैं सहमत नहीं हूं कि यह एक अच्छा तरीका है। मूल रूप से, आप कह रहे हैं कि जो कोई भी विकास के लिए संपादन योग्य इंस्टॉल का उपयोग करना चाहता है उसे तैनाती के लिए pyproject.toml PEP-517/518 को भी छोड़ना होगा।

@pfmoore इस बीच हम संपादन योग्य इंस्टॉल पर सहमत हैं क्या हम अभी भी विरासत संपादन योग्य इंस्टॉल मोड (कुछ अजीब ध्वज के पीछे) की पेशकश करने की योजना बना रहे हैं या पाइप 19.0.0 ने अभी के लिए संपादन योग्य इंस्टॉल समर्थन छोड़ दिया है, और केवल संयोग से पूर्व 19.1 काम किया है?

हुह? मुझे यकीन नहीं है कि आप यहां क्या पूछ रहे हैं। और मुझे यकीन नहीं है कि इस संदर्भ में "हम" कौन है। लेकिन मेरा व्यक्तिगत विचार है:

1. गैर-पीईपी 517 परियोजनाओं (जिनके पास build-backend में pyproject.toml ) के लिए संपादन योग्य इंस्टॉलेशन अभी भी ठीक उसी तरह समर्थित हैं जैसे कि पिप 19 से पहले। आपको --no-use-pep517 आवश्यकता हो सकती है।
2. पीईपी 517 ने कभी भी संपादन योग्य इंस्टालेशन का समर्थन नहीं किया है, हालांकि पीआईपी 19.0 में कुछ मामले हैं जहां यह पीईपी 517 और विरासत प्रसंस्करण को मिश्रित करने वाले मोड में गिर गया। उन मामलों में 19.0 में समस्याएं थीं, हमने उन्हें "पीईपी 517 संपादन योग्य इंस्टॉल का समर्थन नहीं करता" सिद्धांत के अनुरूप तय किया, यह स्पष्ट करके कि संपादन योग्य मोड पीईपी 517 द्वारा समर्थित नहीं था।

जाहिरा तौर पर (याद रखें, यह सिर्फ मेरी राय है!) ऐसे बहुत से लोग हैं जिन्होंने पीईपी 517 को "संपादन योग्य इंस्टॉल का समर्थन नहीं करता" मुद्दे के बारे में बहुत अधिक चिंता किए बिना चुना, जो पीआईपी के प्रकार के समर्थन पर भरोसा करते थे। वे अब उपरोक्त (2) के कारण संघर्ष कर रहे हैं, और यह अच्छा होगा यदि पिप के पास उनके लिए कोई उत्तर हो। मैं उस उत्तर को मानक-आधारित होना पसंद करूंगा, लेकिन मैं सराहना करता हूं कि यह अल्पकालिक फिक्स नहीं है। अगर कोई शॉर्ट-टर्म फिक्स (एक पीआर) प्रदान करता है तो मैं उस स्तर पर उस पर एक नज़र डालूंगा, लेकिन मैं किसी भी प्रकार के --make-it-go-away विकल्प की शैली के लिए उत्सुक नहीं हूं - मैं इसके बजाय जो कुछ भी किया जाता है वह उस पिप में बेहतर फिट बैठता है जो पहले से ही है।

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

पुनश्च एक संभावित विकल्प (@cjerdonek - मैं नहीं जानता कि यह कैसे व्यावहारिक हो सकता है, हो सकता है आप टिप्पणी कर सकते हैं?) जिन स्थानों पर हम जुटाने को बदलने के लिए होगा make_editable_error (मजबूत बजाय सिर्फ एक के रूप में संदेश की रिपोर्ट करना ) चेतावनी, यह कहते हुए कि पीईपी 517 परियोजनाओं के साथ संपादन योग्य का उपयोग करना अपरिभाषित है, और आप इसे अपने जोखिम पर उपयोग करते हैं - लेकिन फिर बिना बढ़ाए आगे बढ़ते हैं। यदि वह पुराने व्यवहार पर वापस आता है, तो उपयोगकर्ता को चेतावनी दी गई है लेकिन हम उनके निर्माण को नहीं रोकते हैं। मुझे उम्मीद है कि अगर हम ऐसा करते हैं, तो हम अजीब व्यवहार का अनुभव करने वाले उपयोगकर्ताओं के लिए समर्थन की पेशकश नहीं करते हैं यदि यह संदेश प्रदर्शित किया गया था ... (मैं इस व्यवहार के लिए परीक्षण जोड़ने की जहमत नहीं उठाऊंगा, या ऐसा कुछ भी - इसे वास्तव में असमर्थित बनाएं )

मैं stderr - PEP-517 detected but editable install requested, this combination is not supported, will fallback to pre PEP-518/7 mode पर लिखी गई एक बड़ी लाल चेतावनी के साथ ठीक हो जाऊंगा; @cjerdonek ?

पुनश्च. हम PyPa के रूप में, PyPa पैकेज के अनुरक्षक हैं।

ध्यान दें कि मैं "पूर्व पीईपी -517/8 मोड में फॉलबैक" करने के लिए प्रतिबद्ध नहीं हूं - वास्तविकता यह है कि मुझे लगता है कि यह "कुछ अजीब फ्रेंकस्टीन मोड पर वापस आ गया है जो वहां कुछ पीईपी 518 के साथ ज्यादातर विरासत है" :-) लेकिन मुद्दा यह है कि मैं वास्तव में नहीं जानता कि यह क्या करेगा।

सुनिश्चित नहीं है कि आप "PyPA" से समग्र रूप से एक राय कैसे प्राप्त करेंगे, ऐसा करने का एकमात्र औपचारिक तरीका मानक है। मैं केवल अपनी व्यक्तिगत राय दे सकता हूं, और अधिकांश पीपीए लोग पाइप ट्रैकर का पालन नहीं करते हैं। हम अभी तक पिप अनुरक्षकों से आम सहमति की राय देखने के करीब भी नहीं हैं...

@pfmoore यह pyproject.toml बिना समान नहीं होगा, जिसका अर्थ है कि उसी राज्य ने PEP-517/PEP-518 से पहले किया था - शायद इसका अर्थ केवल python setup.py develop आह्वान करना है जब तक कि हम एक मानकीकृत विकास प्राप्त न करें तरीका।

ध्यान दें कि मैं "पूर्व पीईपी -517/8 मोड में फॉलबैक" करने के लिए प्रतिबद्ध नहीं हूं - वास्तविकता यह है कि मुझे लगता है कि यह "कुछ अजीब फ्रेंकस्टीन मोड पर वापस आ गया है जो वहां कुछ पीईपी 518 के साथ ज्यादातर विरासत है" :-) लेकिन मुद्दा यह है कि मैं वास्तव में नहीं जानता कि यह क्या करेगा।

मुझे एहसास है कि पिछली बार पीईपी 517 में बदलाव के बाद हमें pip ~=18 पीईपी 518 व्यवहार प्राप्त करने में बहुत परेशानी हुई थी, लेकिन मुझे लगता है कि आदर्श स्थिति पीआईपी के पीईपी 518 व्यवहार पर वापस आना होगा (यानी निर्माण करना पृथक निर्माण वातावरण), फिर setup.py develop आह्वान करें।

नमस्ते,
पूरी सुबह यह जानने की कोशिश में बिताई कि आज मेरे पैकेजों का निर्माण क्यों बंद हो गया। यह काम पर मेरा विन्यास है:

pipenv 2018.11.26 एक नया वर्चुअलएन्व बनाएं जिसमें (आज से) pip 19.1 डिफ़ॉल्ट रूप से स्थापित है। निम्न अनुभाग के साथ प्रोजेक्ट रूट डीआईआर में pyproject.toml फ़ाइल है:

[build-system]
requires = [
    "setuptools",
    "wheel",
]

जिसका अर्थ है कि "बिल्ड-बैकएंड" परिभाषित है, मुझे लगता है। सुविधा कारणों (परीक्षण, और इसी तरह) के लिए पैकेज को संपादन-मोड में स्थापित किया गया है। pyproject.toml में black और tidypy लिए सेटिंग्स भी शामिल हैं। @pfmoore याद कर सकते हैं नहीं तुम कहाँ है कि बस काला उपयोग कर रहा है उल्लेख किया pyproject.toml अपनी सेटिंग्स के लिए, लेकिन जाहिरा तौर पर भी tidypy कि कर रही है।

चूंकि मैं pipenv ( pip सीधे नहीं) का उपयोग करता हूं, --no-use-pep517 काम करने में सक्षम नहीं था (क्योंकि संस्करण 2018.11.26 इसका समर्थन नहीं करता है)। मेरे पर्यावरण को काम पर वापस लाने का एकमात्र तरीका export PIP_USE_PEP517=false । यदि इसे पूरा करने का कोई बेहतर तरीका है (कम से कम कुछ समय के लिए कृपया बेझिझक झंकार करें)।

इससे पहले आज सुबह (इस मुद्दे के खुलने से पहले) मैंने बिना किसी सफलता के pyproject.toml फ़ाइल से [build-system] अनुभाग को निकालने का भी प्रयास किया है, इसलिए मुझे यकीन नहीं है कि साथ/ "बिल्ड-बैकएंड" के बिना असली है या यह सिर्फ मुझे कुछ गलत हो रहा है।

मेरी परियोजनाओं में, मैं निश्चित रूप से (ए) व्यवहार को साबित करने के लिए, (बी) सर्वोत्तम प्रथाओं में ऑप्ट-इन करने के लिए, और (सी) कार्यक्षमता निर्दिष्ट कर रहा हूं।

कई परियोजनाओं में, 'संपादन योग्य' कार्यप्रवाह वह है जो सबसे लगातार काम करता है (प्रतिलिपि में निहित स्थिरता और दोहराव से संबंधित मुद्दों से बचना जो एक अंतर्निहित स्थापना आवश्यक रूप से बनाता है)।

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

हमारी देव टीम जिन विकल्पों पर विचार कर रही है:

• ब्लॉक पिप 19.1 और बाद में पैकेज इंडेक्स पर
• संपादन योग्य परियोजनाओं का उपयोग करना बंद करें और परिणामों से निपटें
• पुराने पाइप को पिन करने के लिए हैक टॉक्स

मैं --really-ignore-pep517-for-develop-mode जैसे दृष्टिकोण को अधिक पसंद करूंगा जिसे बर्नट ने प्रस्तावित किया था।

हम यहां जो भी वर्कअराउंड टॉक्स लेकर आएंगे, वह तेजी से इसे अपनाएगा, जब तक कि यह डेवलपर मोड को pyproject.toml को हटाए बिना काम करता है। और हाँ उस कुएँ का एक बड़ा लाल संदेश प्रिंट किया जा सकता है कि FYI करें आप असमर्थित भूमि में हैं।

@pfmoore यह pyproject.toml बिना समान नहीं होगा, जिसका अर्थ है कि उसी राज्य ने PEP-517/PEP-518 से पहले किया था - शायद इसका मतलब केवल python setup.py develop आह्वान करना है जब तक कि हम एक मानकीकृत विकास प्राप्त न करें तरीका।

@pfmoore यह pyproject.toml के बिना समान नहीं होगा, जिसका अर्थ है कि उसी राज्य ने PEP-517/PEP-518 से पहले किया था - शायद इसका मतलब है कि जब तक हम एक मानकीकृत विकास मोड प्राप्त नहीं करते तब तक केवल python setup.py विकसित करें।

मुझे नहीं पता, ईमानदार जवाब है। PEP 517 सपोर्ट जोड़ने से पहले कोड अब बहुत अलग है।

आइए इसका पता लगाएं और समाधान बनाएं मेरा प्रस्ताव है। क्या हम उस पर सहमत हो सकते हैं, जबकि इस बीच हमें पीईपी-517 संपादन योग्य मोड मिलता है:

मुझे लगता है कि आदर्श स्थिति पाइप के पीईपी 518 व्यवहार (यानी पृथक निर्माण वातावरण का निर्माण) पर वापस आना होगा, फिर setup.py विकसित करें।

होने का सही तरीका है; एक बड़े लाल संदेश के साथ यह कहते हुए कि जैसे ही हम उचित PEP-517 संपादन योग्य मोड प्राप्त करेंगे, यह व्यवहार बदल जाएगा। यदि ऐसा है तो मैं ऐसा करने के लिए एक पीआर बनाने की कोशिश कर सकता हूं, और इसे 19.1.1 रूप में जारी कर सकता हूं।

यह लोगों को वितरण के लिए पीईपी-517/8 सर्वोत्तम प्रथाओं का पालन करने की अनुमति देगा लेकिन विकास के लिए कुछ समझदार (जो किसी बिंदु पर बदल जाएगा) पर वापस आ जाएगा।

@gaborbernat मेरा मानना ​​​​है कि @ncoghlan ने PEP 518 व्यवहार को बहाल करने में एक दरार ली, जब हम पहली बार सापेक्ष आयात के मुद्दे से निपटने के लिए पांव मार रहे थे और अंततः इसे छोड़ दिया। उसके विचार हो सकते हैं कि यह कितना संभव है।

यह देखते हुए कि हम वास्तव में दो बार "केवल पीईपी 518 पर वापस आना" विकल्प चाहते हैं, मुझे ऐसा लगता है कि यह प्रयास करने लायक है।

स्पष्ट करने के लिए pip विकल्प के रूप में "पीईपी 518 पर वापस आना" नहीं है। मेरी समझ यह है कि जब PEP 517 समर्थन जोड़ा गया था, तो इसे PEP 518 समर्थन के स्थान पर जोड़ा गया था, इसलिए दोनों अटूट रूप से जुड़े हुए हैं। एक कोड पथ होना जो pip ले सकता है जो कुछ परिदृश्यों में पीईपी 518 पर वापस आ सकता है, "त्वरित सुधार" पैच को लागू करने के लिए हमें अब दो बार आवश्यकता है।

मैं इसे स्वयं अक्षम-सक्षम PEP-517 जैसे नहीं बनाऊंगा। लेकिन इसके बजाय, केवल संपादन योग्य इंस्टॉल के मामले में अक्षम करें।

_(यह शायद एक अलग चर्चा का विषय है लेकिन मैं इसे यहां बताऊंगा)_

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

PS एक संभावित विकल्प ( @cjerdonek - मुझे नहीं पता कि यह कितना व्यावहारिक होगा, हो सकता है कि आप टिप्पणी कर सकें?)

यह सीधा होगा (अनिवार्य रूप से उपयुक्त मामलों में चेतावनी लॉग करने और परीक्षण मामलों को अपडेट करने के लिए केवल raise को बदलना)। प्रासंगिक कोड यहां शुरू होता है:
https://github.com/pypa/pip/blob/9816d17ccaf33dc5450b74ad310b6827915e2fe7/src/pip/_internal/pyproject.py#L136
किसी को बस यह तय करने की जरूरत है कि व्यवहार क्या होना चाहिए। व्यक्तिगत रूप से, @pfmoore जो कुछ भी

मुझे लगता है कि तत्काल अग्निशमन के लिए @pfmoore का सुझाव काफी अच्छा है ...

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

अरे @cjerdonek - इस रिलीज के साथ गुजरने वाले प्रत्येक दिन का मतलब है कि अधिक परियोजनाएं जिन्हें पैच रिलीज प्रक्रिया की आवश्यकता होती है। अगर इसे अगले 36 घंटों में बनाया जा सकता है, तो मैं ख़ुशी से बगफिक्स रिलीज़ पर $50 का इनाम रखूँगा।

@pfmoore स्पष्ट करने के लिए, क्या इस टिप्पणी में आपका प्रस्ताव था कि यदि संपादन योग्य मोड का अनुरोध किया गया है ("बिल्ड-बैकएंड" और बिना- "बिल्ड-बैकएंड" मामलों दोनों के लिए), तो यह स्वचालित रूप से उपयुक्त चेतावनियों के साथ पीईपी 517 प्रसंस्करण से बाहर हो जाता है? या फिर दोनों ही मामलों में --no-use-pep517 आवश्यकता होगी? आपके सुझाव के बारे में मेरी समझ ( --no-use-pep517 की आवश्यकता है या नहीं) यह है कि दोनों मामलों में एक चेतावनी होनी चाहिए कि विरासत व्यवहार समान रूप से काम नहीं कर सकता है, लेकिन इस मामले में शब्दांकन मजबूत होगा कि "बिल्ड -बैकएंड" मौजूद है (कह रहा है कि व्यवहार वर्तमान में कल्पना में अपरिभाषित है)।

उपरोक्त पर, यह मुझे अजीब लगेगा यदि हमें केवल --no-use-pep517 होती है जब "बिल्ड-बैकएंड" मौजूद नहीं होता है। इसका मतलब यह होगा कि जब संपादन योग्य मोड का उपयोग किया जा रहा हो तो "बिल्ड-बैकएंड" जोड़ना --no-use-pep517 पास करने के समान प्रभाव होगा (केवल चेतावनी टेक्स्ट अलग होगा)।

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

लेकिन मुझे इस बात का बिल्कुल भी अहसास नहीं है कि यहाँ "अच्छा" विकल्प क्या होगा। यदि स्थिति काफी गंभीर है, तो #6314 और #6331 को वापस करने की आवश्यकता हो सकती है। यदि नहीं, तो किसी को यह तय करने की आवश्यकता है कि वर्तमान टूट-फूट को ठीक करते हुए उन दो पैच की भावना को कैसे संरक्षित किया जाए। लेकिन "स्विच ऑफ पीईपी 517" ब्लंट इंस्ट्रूमेंट विकल्प से खुश नहीं होने के अलावा, मेरे पास इस मुद्दे पर सोचने का समय नहीं है।

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

आगे के रास्ते के बारे में, मेरी भावना यह है कि --no-use-pep517 दोनों ही मामलों में या न तो ("बिल्ड-बैकएंड" कुंजी के साथ या उसके बिना) की आवश्यकता होनी चाहिए। जब व्यवहार में भविष्य में बदलाव की बात आती है तो उस विकल्प का परिणाम ट्रेडऑफ़ में होता है। अगर हमें अभी ध्वज की आवश्यकता नहीं है, तो लोग शिकायत करेंगे जब पीईपी 517 संपादन योग्य के लिए समर्थन जोड़ता है और चीजें अलग तरह से व्यवहार करती हैं, और शायद पीईपी 517 के लिए संपादन योग्य पर विचार करते समय हम क्या विकल्प चुन सकते हैं। अब, समस्या यह है कि लोग शिकायत कर सकते हैं कि विकल्प का उपयोग करना असुविधाजनक है और शायद यह सभी मामलों में सही ढंग से काम नहीं करता है (उदाहरण के लिए नेस्टेड आवश्यकताओं फ़ाइल के साथ समस्या)।

मैं आपके विश्लेषण से सहमत हूं। मेरी प्राथमिकता इसे स्पष्ट करने के लिए --no-use-pep517 आवश्यकता होगी। अगर मैं उपरोक्त टिप्पणियों को समझता हूं, तो यह अनिवार्य रूप से --no-use-pep517 कार्य को --make-it-just-work ध्वज के समान बनाता है जिसे लोग मांग रहे थे, इसलिए मुझे लगता है कि यह एक स्वीकार्य असुविधा होनी चाहिए।

मैंने अभी एक प्रारंभिक पीआर पोस्ट किया है (https://github.com/pypa/pip/pull/6442) समीक्षा के लिए जो @pfmoore और मैंने ऊपर वर्णित किया है।

वर्कअराउंड की तलाश में हर किसी के लिए - आप इस पर विचार कर सकते हैं:

1. पिप 19.0 का उपयोग करना;
2. export PIP_USE_PEP517=false (क्रेडिट: @ariciputi );
3. यदि pyproject.toml केवल black , तो आप इसका नाम बदल सकते हैं और black --config black_config.toml . उपयोग कर सकते हैं;
4. संपादन योग्य मोड का उपयोग नहीं करना;

@dxxxdk की सूची को

1. https://github.com/ansible/molecule/pull/2009 / https://github.com/jaraco/skeleton/commit/123b0b2 (क्रेडिट: @jaraco);

धन्यवाद! अब हमें बस एक रिलीज की जरूरत है, @dstufft

जिसका अर्थ है कि "बिल्ड-बैकएंड" परिभाषित है, मुझे लगता है।

@ariciputi pyproject.toml सामग्री जो आपने यहां अपनी है , केवल "बिल्ड-सिस्टम" अनुभाग में "आवश्यकता" कुंजी है, न कि "बिल्ड-बैकएंड" कुंजी। जब संदेश "बिल्ड-बैकएंड" कुंजी का उल्लेख करता है, तो इसका मतलब है कि शाब्दिक स्ट्रिंग को toml फ़ाइल में होने की आवश्यकता होगी।

@pfmoore @cjerdonek मैं वजन करने से पहले मूल मुद्दों को थोड़ा और करीब से देखने की उम्मीद कर रहा था, लेकिन मुझे यकीन नहीं है कि इस समय मेरे पास ऐसा करने का समय होगा, इसलिए मैं बस जा रहा हूं शूटिंग यहाँ कूल्हे से। मुझे लगता है कि लोगों को पीईपी 517 से बाहर निकलने के लिए मजबूर किए बिना pip -e को कम से कम काम करने के

दिन के अंत में, मुझे पूरा यकीन है कि पीईपी 517 अपनाने के लिए हमें संपादन योग्य इंस्टॉल या कुछ और की आवश्यकता होगी, इसलिए जब हम एक मानक के साथ आते हैं तो अस्थायी रूप से संपादन योग्य इंस्टॉल से लोगों को माइग्रेट करना प्रतिकूल लगता है। मुझे लगता है कि करने के लिए वापस आने setup.py develop आवश्यकता नहीं होनी चाहिए --no-use-pep517 या तो मामले में, बस चेतावनी स्वचालित रूप से जारी करते हैं।

यहां चर्चा के लिए कुछ देर हो चुकी है, लेकिन मेरी अधिकांश परियोजनाएं उस श्रेणी के अंतर्गत आती हैं जिसका @gaborbernat वर्णन करता है -- मेरे पास -e . मेरे requirements-dev.txt , और उनके लिए एक नया देव वातावरण स्थापित करते समय मैंने अभी-अभी $ pip install -r requirements-dev.txt ।

मुझे नहीं पता कि python setup.py develop समाधान कितना सामान्य है, लेकिन एक प्रोजेक्ट में मैंने इसे अभी तक ठीक करने की कोशिश की है। (मैं src कॉन्फ़िगरेशन का उपयोग कर रहा हूं, और मुझे विशेष रूप से प्रोजेक्ट वर्किंग डायरेक्टरी को पर्यावरण में स्थापित करने की आवश्यकता है ताकि परीक्षण सूट पैकेज को आयात कर सके।)

यदि setup.py develop इनमें से अधिकांश समस्या मामलों के लिए एक सामान्य स्टॉपगैप समाधान हो सकता है (यह पता नहीं है कि यह होगा या नहीं), तो यह "PEP517 के साथ संपादन योग्य इंस्टॉल समर्थित नहीं है" त्रुटि संदेश को बढ़ाने के लिए पर्याप्त हो सकता है, जैसे कुछ :

.... Until editable install support is defined and implemented for PEP517 setuptools projects, running 'python setup.py develop' may be a suitable workaround.

एफडब्ल्यूआईडब्ल्यू, मैंने अपनी आवश्यकताओं की फाइलों में python setup.py develop के विकल्प के रूप में -e . विकल्प के रूप में अभी परीक्षण किया है, और मेरा परीक्षण सूट स्थानीय रूप से पास हो गया है, मेरा सीआई ठीक है , और टॉक्स (v3.9, अप टू डेट) पूरी तरह से संतुष्ट था:

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

अगर यह मदद करता है, तो मैंने #6438 को ठीक करने के लिए पीआर #6447 पोस्ट किया और आवश्यकता फाइलों में --no-use-pep517 (और --use-pep517 ) का उपयोग करने की अनुमति दी।

@pganssle IMO, यह कुछ प्राथमिकता के मामले के रूप में संपादन योग्य मोड का समर्थन करने के लिए PEP 517 एक्सटेंशन पर काम करना शुरू करने की आवश्यकता पर जोर देता है।

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

मुझे इस ट्रेन में थोड़ी देर हो गई है, लेकिन मैं कहूंगा कि आदर्श रूप से एक आवश्यकता पर -e निर्दिष्ट करना वर्तमान में केवल इस आवश्यकता के लिए --no-use-pep517 होना चाहिए।

@pfmoore हाँ, मैं मानता हूँ कि हमें इस पर काम करना शुरू करने की आवश्यकता है, मैंने वास्तव में ऐसा होने से पहले पैकेजिंग मिनी-शिखर सम्मेलन में इस पर चर्चा करने का प्रस्ताव दिया था, और एक टन वर्कफ़्लो को तोड़ने से इसे पूरा करने की आवश्यकता ही बढ़ गई है।

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

यह शायद अनुभवहीन है, और पहले से ही संपादन योग्य इंस्टॉल पर पूर्व चर्चा में शामिल किया गया हो सकता है, लेकिन: संपादन योग्य इंस्टॉल को सक्षम करना उतना ही सरल ("सरल") हो सकता है जितना कि editable_install फ़ील्ड को [build-system] में जोड़ना pyproject.toml ? यह संपादन योग्य स्थापना प्राप्त करने के लिए निष्पादित करने के लिए (श्रृंखला) कमांड को धारण करेगा; और, अन्य [build-system] फ़ील्ड के लिए डिफ़ॉल्ट की तरह ही setuptools को बिल्ड बैकएंड के रूप में मानते हैं, डिफ़ॉल्ट editable_install=python setup.py develop ?

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

इसके लिए शायद पहले PEP517/518 में संशोधन की आवश्यकता होगी, हालांकि...?

@bskinn संपादन योग्य इंस्टॉल एक बैकएंड सुविधा है, इसलिए किसी विशेष बैकएंड का उपयोग करके किसी विशेष मंत्र को उनकी pyproject.toml फ़ाइल में कॉपी करने के लिए प्रत्येक प्रोजेक्ट की आवश्यकता का कोई मतलब नहीं है - इसके बजाय उनकी जरूरतों को फ्रंटएंड के लिए पूछने का एक तरीका होना चाहिए स्थानीय संपादन योग्य संस्थापन बनाने के लिए बैकएंड।

हमने चर्चा को https://discuss.python.org/t/pip-19-1-and-installing-in-editable-mode-with-pyproject-toml/1553 पर स्थानांतरित कर दिया है

हेलो सब लोग,

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

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

pyproject.toml (और/या build-backend अनुभाग के साथ) वाली परियोजनाएं आभासी वातावरण का उपयोग करके कैसे विकसित होती हैं ( PYTHONPATH निश्चित रूप से सेट करने के अलावा)?

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

यह विशुद्ध रूप से मेरा व्यक्तिगत विचार और कार्यप्रवाह है, बिल्कुल।

बस ध्यान दिया कि pip install -e 19.1 का उपयोग करते समय पाइप के साथ ही विफल हो गया, लेकिन अब इसे मास्टर गैर-संपादन योग्य से स्थापित करने के बाद काम करता है।
मैं आमतौर पर संपादन योग्य इंस्टॉल का भी उपयोग करता हूं, क्योंकि यह आसानी से पैच के लिए संस्करण-नियंत्रित फ़ाइलों को संपादित करने की अनुमति देता है।

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