Pipenv: केवल एक बंद निर्भरता को अद्यतन करना

यह pipenv install लिए भी उपयोगी हो सकता है, क्योंकि कभी-कभी मैं दूसरों को अपडेट किए बिना एक नई निर्भरता स्थापित करना चाहता हूं।

यहाँ एक छोटी सी बात को ध्यान में रखना है: एकल निर्भरता को बदलना आवश्यकताओं के समग्र सेट को बदल सकता है।
Ex: 1.0 से 2.0 तक foo का अपडेट करने के लिए bar लेकर = = 2.0 तक अपडेट करना पड़ सकता है (जबकि यह पहले <2.0 था), और इसी तरह।

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

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

आशा है कि ये आपकी मदद करेगा!

वास्तव में, यही मेरा मतलब था:

यह केवल मेरे भयानक-डिपो और इसकी निर्भरता के अपडेट के साथ एक Pipfile.lock उत्पन्न करेगा।

100% सहमत - और मैं थोड़ा आगे जाऊंगा: यह डिफ़ॉल्ट होना चाहिए।

यानी pipenv install foo को कभी भी foo और उसकी निर्भरता के अलावा कुछ भी नहीं छूना चाहिए। और pipenv lock को निश्चित रूप से कभी भी कुछ भी अपग्रेड नहीं करना चाहिए - यह सिर्फ उस लॉक होना चाहिए जो पहले से इंस्टॉल है।

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

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

बस इस संबंधित मुद्दे को भी मिला: https://github.com/kennethreitz/pipenv/issues/418

pipenv install --upgrade-strategy=only-if-needed निर्दिष्ट करने में सक्षम होने के नाते ऐसा लगता है कि मैं क्या देख रहा हूं, हालांकि जैसा कि मैंने उल्लेख किया है कि मुझे लगता है कि डिफ़ॉल्ट होना चाहिए, क्योंकि यह पाइप 10 में बन रहा है। लेकिन इसे अर्ध-स्थायी रूप से निर्दिष्ट करने में सक्षम होने के नाते env var कुछ भी होगा।

मुझे आश्चर्य होगा कि अगर यह परिवर्तन किसी के वर्कफ़्लो ( प्रसिद्ध अंतिम शब्द ) को तोड़ देता है, क्योंकि यह --upgrade-strategy=eager से अधिक रूढ़िवादी है।

मेरे शेल कॉन्फ़िगरेशन में export PIP_UPGRADE_STRATEGY=only-if-needed सेट करके इसके चारों ओर काम करने की कोशिश की। यह काम नहीं करता है, और pipenv lock इन आश्चर्यजनक व्यवहारों को प्रदर्शित करता है:

1. यह "अपग्रेड" पैकेज है जिन्हें अपग्रेड करने की आवश्यकता नहीं है (लेकिन ...)
2. यह वास्तव में स्थापित संस्करणों को अपग्रेड नहीं करता है! यानी pip freeze और Pipfile.lock अलग-अलग संस्करण दिखाते हैं!

लगता है कि pipenv स्थापित करने के लिए पाइप करने के लिए प्रतिनिधि है, और पाइप इसकी पर्यावरण चर सेटिंग्स का सम्मान करता है, लेकिन pipenv lock नहीं करता है।

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

@brettdh मुझे लगता है कि मैं कुछ प्रकाश डाल सकता हूं क्योंकि आपके पास अधिकांश टुकड़े हैं। pipenv lock कुछ भी स्थापित नहीं करता है, और यह दावा नहीं करता है। यह केवल आपके होस्ट वातावरण, पायथन संस्करण और दिए गए Pipfile के लॉकफ़ाइल को उत्पन्न करता है। यदि आप किसी अन्य तरीके से अपने वातावरण में हेरफेर करते हैं या यदि आप सीधे पाइप का उपयोग करते हैं / पिपेनव के बाहर पाइप सेटिंग्स में हेरफेर करते हैं / pipenv run का उपयोग नहीं कर रहे हैं या किसी pipenv सब-इन के अंदर pip freeze उपयोग कर रहे हैं, तो यह काफी आसान है pip freeze से सिंक से बाहर होने के लिए एक ताला। दोनों वास्तव में संबंधित नहीं हैं।

स्पष्ट होना:

1. Pipfile.lock उपयोगकर्ता के Pipfile आधार पर पाइप-टूल रिज़ॉल्वर का उपयोग करके एक कड़ाई से पिन करने वाली निर्भरता संकल्प है
2. यदि आप केवल एक पैकेज को अपग्रेड करते समय हर चीज के सख्त पिन को बनाए रखना चाहते हैं, तो मेरा मानना ​​है कि आप ऐसा कर सकते हैं अपने Pipfile में सब कुछ सख्ती से पिन करके आप जिस चीज को अपग्रेड करना चाहते हैं, उसे छोड़कर (मुझे गलत होने पर सही करें) @vphilippon)

आपके लॉकफाइल और pip freeze एक-दूसरे से असहमत होने के कारण, मुझे अधिक जानकारी प्राप्त करनी होगी, लेकिन मेरा मानना ​​है कि समाधान के लिए गैर-सिस्टम संस्करणों का उपयोग करते समय हमारे पास हमारे लॉकफ़ाइल रिज़ॉल्वर के बारे में एक खुला मुद्दा है।

@techalchemy : यदि मेरे पास A, B और C के साथ Pipfile.lock है, जहां B A की निर्भरता है, तो मैं A और B को C, या C को अपडेट किए बिना A और B को अपडेट किए बिना सक्षम होना चाहूंगा।
फिर से मैं ऐसा करने के लिए अपने सभी निर्भरता और उनकी निर्भरता को अपने Pipfile में पिन कर सकता हूं, लेकिन यह एक बोझ बनाए रखना होगा (जैसे कि requirements.txt हैं)।

मैं सब कुछ @ k4nar ने लिखा। यकीन है, मैं भी सिर्फ पिन कर सकता है
आवश्यकताओं में सब कुछ। पिपंनव की बात है
एक उपकरण है कि बनाता है (और virtualenv सामान, निश्चित रूप से)
प्रबंधन करने के लिए सरल; यानी सभी पैकेज डिफ़ॉल्ट रूप से एक संस्करण में बंद हैं
यह काम करने के लिए जाना जाता है, लेकिन किसी चयन को अपग्रेड करने के लिए यह सीधा होना चाहिए
कुछ (अप्रत्याशित रूप से दूसरों को अपग्रेड किए बिना)।
Thu पर, 26 अक्टूबर, 2017 को सुबह 4:28 बजे Yannick PUXROUX सूचनाएं @github.com
लिखा था:

@techalchemy https://github.com/techalchemy : यदि मेरे पास एक Pipfile.lock है
A, B और C के साथ जहां B A की निर्भरता है, मैं चाहूंगा कि मैं सक्षम हो जाऊं
A और B को अपडेट किए बिना A और B को अपडेट करें, A और B को अपडेट किए बिना।
निश्चित रूप से मैं अपनी सारी निर्भरता और अपनी निर्भरता को अपने में समाहित कर सकता हूं
ऐसा करने के लिए Pipfile, लेकिन वह बनाए रखने के लिए एक बोझ होगा (जैसे)
अधिकांश आवश्यकताएँ।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/kennethreitz/pipenv/issues/966#issuecomment-339591917 ,
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAFlnqUOEKARiFD8kEk3GVczF3NXBdVOks5swEKcgaJpZM4QEf--
।

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

@techalchemy मैंने pip freeze अंतर का उल्लेख "पैकेज संस्करणों के लिए एक शॉर्टहैंड के रूप में किया है कि pipenv install इंस्टॉल पैकेज संस्करणों से भिन्न होता है कि pipenv lock Pipfile.lock " बचाता है। "

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

क्या आप अपने प्रश्न को थोड़ा स्पष्ट कर सकते हैं? मुझे लगता है कि "पाइप-टूल्स के साथ समाधान" का जिक्र है कि pipenv lock क्या कर रहा है, और इसका कारण क्या है जब मैं पाइप डिफॉल्ट सेट करता हूं? और क्या आप "इस व्यवहार" से आपके बारे में अधिक विशिष्ट हो सकते हैं?

@brettd लॉकिंग तंत्र में "निर्भरता संकल्प" की धारणा शामिल है जो pip में मौजूद नहीं है। pip-tools (या इसके बजाय, इसका एक पैच संस्करण, pipenv द्वारा मूल तरीके से कुछ अंतर लाने वाले विशेष तरीके से एकीकृत) द्वारा नियंत्रित किया जाता है। संक्षेप में, लॉकिंग तंत्र Pipfile पढ़ता है और पैकेज के एक पूर्ण सेट का चयन करने के लिए पूर्ण निर्भरता रिज़ॉल्यूशन करता है जो आवश्यक पैकेजों और उनकी निर्भरताओं द्वारा परिभाषित हर बाधाओं को पूरा करेगा।

@techalchemy

[...] यह पाइप-टूल्स से हल हो रहा है जो मुझे चिंतित करता है।

मुझे यकीन है कि कैसे नहीं उन हूँ --upgrade-strategy असर पड़ेगा pip-tools , क्योंकि इसके बारे में कुछ निम्न स्तर के internals पर काम करता है pip । मुझे लगता है कि यह अपेक्षित परिणाम नहीं देगा, क्योंकि ये विकल्प इस बात को ध्यान में रखते हैं कि क्या स्थापित किया गया है, और यह कि उस तंत्र से निपटा नहीं जा रहा है। लेकिन हमारे पास pip-tools में इसके लिए एक और दृष्टिकोण है जो यहां किया जा सकता है।

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

pip-tools कार्यों के मेरे फिर से शुरू होने की ओर इशारा करते हुए: https://github.com/kennethreitz/pipenv/issues/875#issuecomment -337717817
"उम्मीदवार का चयन करें" भाग याद रखें? यह Repository ऑब्जेक्ट को क्वेरी करके किया गया है।
में pipenv , हम सीधे एक कॉन्फ़िगर PyPIRepository के लिए Resolver , लेकिन pip-tools कुछ और, यह एक का उपयोग करता है LocalRequirementsRepository वस्तु है, जो पहले से मौजूद requirements.txt (यदि पाया गया), और " PyPIRepository " पर "कमियां" से मौजूदा पिन रखता है।

तो pip-tools , उम्मीदवार का चयन करते समय निम्नलिखित होता है:

1. एक उम्मीदवार के लिए LocalRequirementsRepository जो foobar>=1.0,<2.0 मेल खाते हैं।
2. जांचें कि क्या मौजूदा पिन उस आवश्यकताओं को पूरा करता है:
   
   
   
   • यदि हाँ, तो उस पिन को उम्मीदवार के रूप में वापस करें।
   
   
   • यदि नहीं, तो उम्मीदवार के लिए proxied_repository ( PyPIRepository ) की क्वेरी करें।
   
   
3. लौटे उम्मीदवार का उपयोग करें

प्रभावी रूप से, इसका मतलब है कि मौजूदा पिन को पहले प्रयास करने के लिए उम्मीदवार के रूप में "प्राथमिकता" दी जाती है।

लेकिन pipenv , वर्तमान में, यह बस:

1. एक उम्मीदवार जो foobar>=1.0,<2.0 मेल खाता है उसके लिए क्वेरी PyPIRepository (सीधे)।
2. लौटे उम्मीदवार का उपयोग करें।

तो, मैं में ताला के लिए एक ही व्यवहार लगता है pipenv पार्स करने के द्वारा किया जा सकता है Pipfile.lock मौजूदा पिन मिलता है और एक का उपयोग करने के LocalRequirementsRepository , जैसे pip-tools अपने pip-compile कमांड में करता है।

@vphilippon आपको इस बात की समझ है कि उस पर अमल कितना मुश्किल होगा?

@techalchemy

• मौजूदा पिन निकालने के लिए Pipfile.lock पार्स करना: उस पर ध्यान नहीं दिया गया। निर्भर करता है कि pipenv में चीजों को कैसे संरचित किया जाता है। हम का एक सेट की जरूरत है InstallRequirements कि में पिन का प्रतिनिधित्व करता है Pipfile.lock ।
• LocalRequirementsRepository उपयोग करना: बहुत आसान है: हमारे वर्तमान PyPIRepository को LocalRequirementsRepository लिए बदलें।

लेकिन, जैसा कि मैं इसे देख रहा हूं, और @brettdh टिप्पणियों के बाद, मुझे कुछ चीजों का एहसास हुआ:

1. वर्तमान डिफ़ॉल्ट pipenv install व्यवहार pipenv lock व्यवहार से मेल नहीं खाता है। pipenv install requests अकेले करने पर requests अपडेट नहीं होगा यदि कोई नया संस्करण सामने आता है (बहुत कुछ सीधे pip install )। हालांकि, कर pipenv lock अपडेट करेगा Pipfile.lock के नवीनतम संस्करण के साथ requests से मेल खाता है Pipfile विनिर्देशक है, और निर्भरता की कमी।
   इसे देखने का 2 मुख्य तरीका है:
   
   
   
   • A) Pipfile.lock डिफ़ॉल्ट रूप से यथासंभव स्थिर रहना चाहिए, जब तक कि वर्तमान परिवेश की तरह रहने के लिए, आवश्यक न हो, तो पिन बदलना न पड़े और केवल उस घटना में बदलाव आए जिससे हम पर्यावरण को बदलते हैं।
   
   
   • बी) Pipfile.lock को नवीनतम संस्करण प्राप्त करने चाहिए जो पर्यावरण की कमी / निर्भरता का सम्मान करते हैं ताकि Pipfile और मुक्त रूप से खुली निर्भरता से लाभ हो, जिससे लगातार नए संगत संस्करणों को प्राप्त करने की अनुमति मिलती है। आपका पर्यावरण फिर आप ताजे लॉक से लाभ के लिए pipenv update चला सकते हैं।
   
   

IMHO, I would align the default behavior, which would be to go with A) by default. Because right now, everytime a lock is performed (i.e. after each installation), new versions can come in, which make the lockfile *drive the update of the environment*, which seems weird. But, this is arguable of course. While in development, I might want to continuously update my requirements to no get stale, like with B), so that should also be easily doable.

1. यहां तक ​​कि अगर हम सही मौजूदा पिन को अपडेट करने से बचने के लिए LocalRequirementsRepository का उपयोग करते हैं, और डिफ़ॉल्ट व्यवहारों को संरेखित करते हैं, तो हमें लॉकिंग भाग के लिए --upgrade और --upgrade-strategy के बराबर की आवश्यकता होगी। । वर्तमान में, कुछ पर्यावरण चर (जैसे PIP_UPGRADE और PIP_UPGRADE_STRATEGY ) को परिभाषित करना pipenv install व्यवहार को प्रभावित करेगा, लेकिन यह pipenv lock को प्रभावित नहीं करेगा, क्योंकि यह प्रभावित नहीं करता है pip-tools का व्यवहार (मैंने पुष्टि की, जैसा कि मैं पहले अनिश्चित था)।
   अन्यथा, Pipfile.lock को हटाने के बिना पर्यावरण को अपडेट करने का कोई तरीका नहीं होगा (क्लूनी लगता है, और "सभी या कुछ भी नहीं") या एक नए संस्करण की आवश्यकता है (मेरा मतलब है कि स्पष्ट pipenv install requests>2.18.4 , जिसके लिए आपको यह जानना आवश्यक Pipfile में स्पेसिफिक को बदलकर, निचले बाउंड को बढ़ाते हुए), जो गलत है। जैसा कि "मूल pip-tools " इससे निपटने के लिए pip कमी नहीं करता है (जैसा कि यह संबंधित नहीं है कि वर्तमान में क्या स्थापित है), यह निर्भरता को अद्यतन करने के लिए निर्दिष्ट करने का विकल्प प्रदान करता है लॉकफ़ाइल, और मौजूदा पैकेजों (या सभी) के लिए पिन को मौजूदा_पिन्स सूची से हटा दें, प्रभावी रूप से PyPI को क्वेरी करने के लिए प्रभावी रूप से वापस आ रहा है। मुझे यकीन नहीं है कि हम इसके साथ "--ग्रुप-रणनीति" की धारणा से कैसे मेल खा सकते हैं।

@techalchemy
इसलिए जब मैं कह रहा था कि यह सिर्फ "डिफ़ॉल्ट व्यवहार को संरेखित करना" काफी आसान था, मुझे अब एहसास हुआ कि इससे पैकेज को अपडेट करने में सक्षम होने के साथ कुछ प्रमुख मुद्दा पैदा होगा (जैसे: अभी नवीनतम संस्करण मिलता है जो मेरी वर्तमान बाधाओं से मेल खाता है) ।

यदि कुछ अस्पष्ट है, तो पूछें, यह लिखते समय बहुत सारे संपादन चले गए।

(निर्भरता संकल्प आसान नहीं है। अच्छा और व्यावहारिक निर्भरता संकल्प और भी बुरा है)

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

बी) Pipfile.lock को नए संस्करणों को मिलना चाहिए जो पर्यावरण की कमी / निर्भरता का सम्मान करते हैं, जिससे कि स्वतंत्र रूप से Pipfile और काम पर निर्भरता में खुली सीमाओं से लाभ मिल सके, जिससे आपके वातावरण में लगातार नए संस्करणों को प्राप्त करने की अनुमति मिलती है। फिर आप ताजे लॉक से लाभान्वित होने के लिए पिपेनव अपडेट चला सकते हैं।

यह वर्कफ़्लो संभवतः वर्तमान कॉन्फ़िगरेशन के साथ काम कर सकता है। आप लॉकफ़ाइल उत्पन्न करने के लिए pipenv lock का उपयोग कर सकते हैं, लेकिन pipenv update पूरे वातावरण को पुनर्स्थापित करेंगे। मुझे पूरा यकीन है कि हम निर्भरता ग्राफ को हल करने के लिए हमारे विभिन्न आउटपुट प्रारूपों में से एक का उपयोग कर सकते हैं (हमारे पास पहले से ही एक जासन प्रारूप है जैसा कि आप जानते हैं) और केवल उन चीजों को पुनर्स्थापित करें जो लॉकफाइल से संरेखित नहीं करते हैं। यह अधिक समझदार हो सकता है, लेकिन मुझे निर्णय लेने से पहले @nateprewitt या @erinxocon के इनपुट के बारे में जानने की उत्सुकता होगी

@vphilippon पूरी तरह से सहमत हैं कि ए और बी विभिन्न स्थितियों में वांछनीय वर्कफ़्लो हैं। B के आसपास आपके कुछ वाक्यांशों ने मुझे थोड़ा भ्रमित कर दिया, हालांकि, यह कहते हुए कि pipenv lock परिणाम एक लॉकफ़ाइल में हो सकता है जो वास्तव में पर्यावरण से मेल नहीं खाता है - मैंने विशेष रूप से इसमें सुना है कि " pipenv update चलाने की आवश्यकता होगी"

भले ही आप A वर्कफ़्लो में हों या B वर्कफ़्लो में, कुछ चीजें मुझे निरंतर लगती हैं, और मुझे लगता है कि यह वर्ग @techalchemy के साथ भी कह रहा है:

• pipenv lock का परिणाम हमेशा पर्यावरण से मेल खाने वाला ताला होना चाहिए।
• pipenv install का परिणाम हमेशा एक ऐसा वातावरण होना चाहिए जो लॉकफाइल से मेल खाता हो।

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

pipenv update समय-समय पर आपको बी मोड में रहने की अनुमति देता है जब तक आप चाहते हैं कि सब कुछ ताजा हो, और pipenv install --upgrade requests की क्षमता वाले पैकेज को प्रभावित किए बिना, एक पैकेज और उसकी निर्भरता के विशिष्ट अपडेट की अनुमति देगा। अनावश्यक रूप से अपग्रेड करने की आवश्यकता नहीं है।

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

B के आसपास आपके कुछ वाक्यांशों ने मुझे थोड़ा भ्रमित कर दिया, हालांकि, यह कहते हुए प्रतीत होता है कि पिपेनव लॉक के परिणामस्वरूप लॉकफ़ाइल हो सकता है जो वास्तव में पर्यावरण से मेल नहीं खाता है

@brettdh यह सही है - pip-tools रिवाल्वर का उपयोग हम Pipfile.lock उत्पन्न करने के लिए करते हैं, वर्चुअलाइजेन से यह नहीं पूछते हैं कि कौन से पैकेजों को स्थापित किया गया है। इसके बजाय, यह Pipfile से पिन की सूची में निर्दिष्ट मानदंडों को पूरा करने वाले पैकेजों की एक सूची को संकलित करता है। क्योंकि रिज़ॉल्वर स्वयं सिस्टम या बाहरी पायथन / पिपेनव / पाइप-टूल इंस्टाल का उपयोग करके चलता है, हम virtualenv में उपयोग किए जाने वाले अजगर के समान संस्करण के साथ संकुल को हल करने के लिए इसे समझाने के लिए कुछ सर्वोच्च बकवास कर रहे हैं। धारणा यह होगी कि pip install चीजें समान रूप से हल करेंगी, लेकिन यह हमेशा ऐसा नहीं होता है, हालांकि यहां तक ​​कि मैं इसके बारे में 100% निश्चित नहीं हूं। लेकिन हाँ, pipenv lock virtualenv के आधार पर उत्पन्न नहीं होता है, यह Pipfile आधार पर उत्पन्न होता है। यह एक डिपेंडेंसी रेजोल्यूशन लॉकफाइल है, न कि एनवायरनमेंट स्टेट पिन।

इस के लिए एक संभावित संकल्प के रूप में: कुछ है जो खुद पाइप वर्तमान में समर्थन करता है, लेकिन pip-compile नहीं है, एक बाधा फ़ाइल की धारणा है।

एक बाधा फ़ाइल एक आवश्यकताओं फ़ाइल से भिन्न होती है, जिसमें वह कहती है " यदि यह घटक स्थापित है, तो इसे इस संस्करण की कमी को पूरा

यह वह विशेषता है जो वर्तमान में pipenv से गायब है, वांछित इनपुट के रूप में Pipfile.lock पीढ़ी के लिए है:

1. नई आवश्यकताओं के इनपुट फ़ाइल के रूप में Pipfile सामग्री अपडेट की गई
2. मौजूदा कमांड में विशेष रूप से नामित संकुल को छोड़कर, Pipfile.lock कमी से मौजूदा निर्भरता का पूरा सेट

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

वर्तमान में समर्थित नहीं है, प्रतिक्रिया के लिए धन्यवाद

@kennethreitz

क्या मतलब है आपका:

1. इस व्यवहार को बदला जाना चाहिए, लेकिन वर्तमान में यह प्राथमिकता नहीं है,
2. इस व्यवहार को कुछ वैकल्पिक के रूप में जोड़ा जाना चाहिए, लेकिन यह वर्तमान में प्राथमिकता नहीं है, या
3. यह व्यवहार नहीं जोड़ा जाना चाहिए?

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

यदि इसके बजाय यह (3) है, और इसे जोड़ा नहीं जाएगा, तो मुझे लगता है कि इस मुद्दे पर हमें कई संख्या में पायथन पैकेज प्रबंधन उपकरणों की हमारी पसंद के लिए अपनी योजनाओं को समायोजित करने की आवश्यकता होगी।

मेरा मतलब है कि यह वर्तमान में समर्थित नहीं है, और मैं प्रतिक्रिया की सराहना करता हूं।

मैं समझता हूं कि यह समर्थित नहीं है। क्या आप यह भी कह रहे हैं कि आप इस व्यवहार को बदलने या विकल्प के रूप में इसे जोड़ने के लिए पीआर को स्वीकार नहीं करेंगे?

मुझे पता नहीं है।

@ k4nar अभी भी इसके लिए एक पीआर करने में दिलचस्पी है? विशेष रूप से, pipenv install --only <dep-to-update जैसा कुछ जो असंबंधित डिपों को अपडेट होने से रोकता है। चूँकि @kennethreitz आगे की चर्चा करने में @aionion और मैं pipenv का उपयोग करना जारी रख सकते हैं)।

मुझे दिलचस्पी है लेकिन मुझे यह पता नहीं है कि इसे लागू करने का सबसे अच्छा तरीका कैसे होगा। कार्रवाई में बहुत सारे घटक हैं (पाइप, पाइप-टूल, पाइपफाइल, पाइपेनव…) और संभवत: बहुत सारे संभावित समाधान।

प्रति https://github.com/kennethreitz/pipenv/issues/966#issuecomment -339707418, यह अपेक्षाकृत सीधा होना चाहिए। यह रिज़ॉल्यूशन लॉजिक बड़े पैमाने पर सिर्फ पाइप-टूल्स से है। मैं एक पीआर प्रस्तुत करने की योजना बना रहा था, लेकिन हम काम खर्च को सही नहीं ठहरा सकते हैं यदि हम इस बारे में बात करने के लिए तैयार नहीं हैं कि हम कैसे चाहते हैं कि हम एपीआई को लिखने के समय को लिखने से पहले देखें।

मैं वर्तमान में एक वैकल्पिक दृष्टिकोण लेने पर विचार कर रहा हूं - जैसा कि पिपफाइल एक मानक है, इसके साथ बातचीत पिपेनव के माध्यम से जाने की आवश्यकता नहीं है, और मैं यहां कुछ अन्य अजीब शब्दार्थों के आसपास काम करना चाहूंगा जैसे कि मौजूदा वर्चुअनव्यू प्रति डब्ल्यूटी। : //github.com/kennethreitz/pipenv/issues/997।

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

pipenv install foo
vim Pipfile.lock  # Manually remove all the unwanted updates
git add && git commit && git push

मुझे लगता है कि मेरी टीम के सदस्यों से यह संवाद करना वास्तव में कष्टप्रद है। विकल्प Pipfile में सटीक संस्करणों में सब कुछ पिन करने के लिए प्रतीत होता है, लेकिन यह पहली जगह में पिपेनव का उपयोग करने के उद्देश्य से बहुत कुछ हरा देता है।

IIUC, यह व्यवहार apt के बराबर है जब भी आप apt install foo चलाते हैं, तब निहित apt dist-upgrade होता है।

यह इस तथ्य से बदतर बना है कि pipenv install Pipfile.lock में pipenv install अद्यतन करता है, लेकिन स्थानीय वर्चस्व में अद्यतनों को स्थापित नहीं करता है। यदि डेवलपर Pipfile.lock के अंतर की सावधानीपूर्वक जांच नहीं करता है, तो वे अभी भी स्थानीय रूप से पुराने संस्करणों का उपयोग कर रहे हैं, लेकिन एक बार जब वे कोड साझा करते हैं, तो अन्य सभी वातावरण आश्चर्यजनक अपडेट देखते हैं। लोगों में Pipfile.lock के अंतर को नजरअंदाज करने की प्रवृत्ति है क्योंकि यह एक ऑटो-जनरेट की गई फ़ाइल मानी जाती है।

मेरा दृढ़ विश्वास है कि " Pipfile द्वारा अनुमत नवीनतम संस्करण में सब कुछ अपडेट करें" स्पष्ट रूप से अनुरोधित ऑपरेशन होना चाहिए जो "इंस्टॉल फ़ू" से अलग हो।

मास्टर में तय किया जाना चाहिए

व्यवहार अभी भी मौजूद है, मैंने इसे pipenv 11.8.3 , @kennethreitz में परीक्षण किया।

@ marius92mc "मास्टर में तय किया गया" टिप्पणी --selective-upgrade और --keep-outdated विकल्पों को हालिया रिलीज़ में जोड़ा गया है: https://docs.pipenv.org/#cmdoption -pireenv-install-keep -रगड़ा हुआ

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

@ncoghlan मुझे लगता है कि एक चीज की जरूरत है (आसान के लिए पूछना, जितना करना आसान नहीं है) _how_ पर एक FAQ है (उन विकल्पों को व्यवहार करते हैं (कम से कम यह अभी भी मेरे लिए भ्रमित है)।

उदाहरण के लिए: --selective-upgrade और --keep-outdated का उपयोग करने पर भी अपडेट किए जाने वाले Pipfile.lock में पुरानी लाइब्रेरी बन जाएगी, यदि वे सीधे "चयनित" पैकेज से संबंधित नहीं हैं तो उन्हें अपडेट किया जाएगा ।

ऐसा लगता है कि कार्यान्वयन कीड़े हो सकते हैं, फिर।

उनका इरादा पिपलफाइल को छोड़ने का है। नए बदलाव को छोड़कर।

मुझे बताएं कि क्या यह एक परीक्षण प्रदान करने के लिए सहायक है।

मुझे लगता है कि आपने हमें जांच के लिए पर्याप्त जानकारी प्रदान की है। मैं अब ऐसा करने की कोशिश करूंगा।

वास्तव में, आपके पिपलफाइल / लॉक बहुत अच्छा होगा, यदि इसमें पुराने परिणाम शामिल हैं।

@ncoghlan , विवरण प्रदान करने के लिए धन्यवाद।
मैंने आपके बताए गए विकल्पों के साथ फिर से प्रयास किया और परिणाम समान प्रतीत होता है, यह अभी भी अन्य पैकेजों को अपडेट करता है, उन्हें Pipfile.lock फ़ाइल में बदलते हुए।

@kennethreitz https://github.com/simonpercivall/pipenv-selective-upgrad-test

इस मुद्दे के बारे में कोई भी अपडेट है, @kennethreitz?

इस पर धीमे उत्तर के लिए क्षमा करें। हमने अभी तक यहाँ प्रतिगमन के मूल कारण को नीचे नहीं उठाया है (मुझे पता है कि मैं व्यक्तिगत रूप से इस सप्ताह के अंत में एक डेटा सेंटर प्रवास को संभाल रहा हूं इसलिए मैं थोड़े धीमे रहा हूं) लेकिन हम अगले कुछ दिनों में इसे हल कर लेंगे।

योगदान हमेशा की तरह स्वागत है!

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

1. Setup.py में निर्भरता के लिए संस्करण प्रतिबंध अद्यतन करें
2. pipenv lock --selective-upgrade ; pipenv sync या pipenv install --selective-upgrade "-e ." चलाएं

@wichert यदि Pipfile को इस तरह से संपादित किया गया है जो वर्तमान लॉक फ़ाइल में क्या है उससे परे न्यूनतम आवश्यक संस्करण को बढ़ाता है, तो --keep-outdated को पहले से ही कवर करना चाहिए जो आपको चाहिए। --selective-upgrade उस मामले के लिए है, जहाँ Pipfile नहीं बदले हैं, लेकिन आप किसी भी नए संस्करण में अपडेट करना चाहते हैं।

@ncoghlan Pipfile इस परिदृश्य में नहीं बदले हैं, केवल setup.py एक निर्भरता के लिए न्यूनतम संस्करण की आवश्यकता को बदलकर, आमतौर पर कुछ और हाल ही में और वर्तमान में Pipfile.lock ।

@wichert pipenv आपके setup.py परिवर्तनों को स्वचालित रूप से कैप्चर नहीं करता है क्योंकि यह सेट-अप नहीं है। यदि आप ऐसा करना चाहते हैं तो आपको pipenv lock चलाना होगा।

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

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

पुनश्च: Pipenv बनाने के लिए धन्यवाद, यह भयानक है <3

हाँ यकीनन। हम इस समय समर्थन करने के लिए रिज़ॉल्वर को फिर से लिख रहे हैं। चाहे वह इस रिलीज़ में ज़मीन पर हो या अगली रिलीज़ पर नज़र बनी रहे

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

@uranusjr FWIW, मैंने @benkuhn की टिप्पणी में तेजी के लिए कोई मांग नहीं देखी है - बस एक सवाल है कि चीजें कहां हैं; यानी क्या काम किया गया है, ताकि बाहर के पर्यवेक्षक अपना अनुमान / निर्णय कर सकें।

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

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

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

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

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

एक वैकल्पिक वर्कफ़्लो के रूप में सुझाव देने के लिए कुछ मैं _इंग_ था जो यह पता लगा सकता है कि इंस्टॉल करते समय _Pipfile_ में किसी विशिष्ट संस्करण पर पिन करना आसान है।

मुझे लगता है कि यह थोड़ा आश्चर्यजनक है, लेकिन पूरी तरह से अनुचित नहीं है कि पिपेनव foo = "*" का अर्थ है "मुझे यह सुनिश्चित करने की आवश्यकता है कि फू का _some_ संस्करण स्थापित किया गया है, उपयोगकर्ता को इसकी परवाह नहीं है"। उस अंत तक, pipenv install --pin foo जैसा कुछ होता है, जिसके परिणामस्वरूप foo = "==1.2.3" foo = "*" पिपफाइल में होता है (जहाँ 1.2.3 foo का वर्तमान नवीनतम संस्करण है) ऐसा लगता है जैसे मदद।

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

(बस एहसास हुआ कि मैं गलत मुद्दे पर टिप्पणी कर रहा हूं। गड़बड़ी के लिए क्षमा करें, कृपया मुझे अनदेखा करें) been

एक वास्तविक उपयोग मामला जिसे मैंने अब कुछ घंटों के लिए संघर्ष किया है: मैं एक Django 2.0 परियोजना में परीक्षण कवरेज को मापना चाहता हूं। यहां तक ​​कि pipenv install --keep-outdated --selective-upgrade --dev coverage नॉन-देव Django पैकेज को संस्करण 2.1 में अपडेट करने पर जोर देते हैं, जो कि कहीं और टूटने के कारण मैं अभी तक उपयोग नहीं कर सकता। वास्तव में संभवतः संस्करणों को तोड़ने के लिए पूरी तरह से असंबंधित संकुल को अपग्रेड किए बिना स्थापित पैकेज के सेट को बदलने का एक तरीका होना चाहिए। नवीनतम संस्करण में टूट-फूट की संभावना हमेशा मौजूद रहेगी।

मैं @rfleschenberg का हल कोशिश _meta hash संपत्ति गलत है।

@ l0b0 यदि आपका आवेदन वास्तव में Django के किसी विशेष संस्करण को संभाल नहीं सकता है, तो मुझे लगता है कि यह आपके Pipfile में प्रतिबंध के बारे में बताता है?

@AlecBenzer जो मुझे setup.py के लिए कुछ की तरह लग रहा है।

@wichert यह भी समझ में आ सकता है (मैं वास्तव में पूरी तरह से स्पष्ट नहीं हूँ कि आप किन परिस्थितियों में एक setup.py और Pipfile दोनों चाहते हैं), लेकिन अगर आपके पास अपने Pipfile में एक पंक्ति है जो कहती है:

Django = "*"

आप pipenv को बता रहे हैं कि आप इसे Django का _any_ संस्करण स्थापित करना चाहते हैं। यदि आप वास्तव में चाहते हैं कि यह 2.0 या उससे कम स्थापित हो, तो इसके बजाय यह बताएं:

Django = "<=2.0.0"

जबकि इस विशेष मामले में पिपेनव बिना किसी वास्तविक कारण के Django को अपग्रेड कर रहा है, यह हो सकता है कि कहीं आप लाइन के नीचे एक पैकेज स्थापित करने का प्रयास करें जिसके लिए Django> 2.0.0 की आवश्यकता होती है, जिस बिंदु पर pipenv खुशी से इसे स्थापित करेगा यदि आपने नहीं बताया है यह है कि आप की जरूरत है <= 2.0.0।

यदि आप वास्तव में यह करना चाहते हैं कि 2.0 या उससे कम स्थापित है, तो इसके बजाय यह बताएं

प्रतिबिंब पर @AlecBenzer , अब मेरे साथ ऐसा होता है कि जब आप एक पैकेज स्थापित करते हैं तो यह ^major.minor.0 निर्दिष्ट करते हैं। जो कि अपग्रेड-टू-लेटेस्ट स्पष्ट रूप से अनुरोध किए जाने पर भी अप्रत्याशित प्रमुख संस्करण अपग्रेड को रोकता है। मुझे आश्चर्य है कि अगर पिपेनव को ऐसा करना चाहिए - लेकिन यह एक अलग मुद्दा होगा।

बेशक, उनकी लॉक फ़ाइल भी मामूली और पैच संस्करणों के आकस्मिक उन्नयन को रोकती है, जो कि यहां अनुरोध किया जा रहा है।

मुझे लगता है कि यह ऊपर और अन्य जगहों पर चर्चा की गई है, लेकिन एनपीएम / यार्न और पिपेनव के बीच डिजाइन स्थान में एक तनाव / व्यापार है। किसी भी पैकेज मैनेजर के पास ये लक्ष्य कुछ सापेक्ष प्राथमिकता के साथ होता है:

• पैकेजों को स्थापित और अपग्रेड करना आसान है
• एक गलत निर्भरता उन्नयन के साथ गलती से अपने ऐप को तोड़ने के लिए इसे कठिन बनाएं

Pipfile में एक सटीक संस्करण को पिन करने में परेशानी यह है कि संकुल को अपग्रेड करना तब कठिन होता है; यही कारण है कि पाइप-टूल मौजूद है (हालांकि यह आवश्यकताओं के लिए है।

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

@brettdh

परावर्तन पर, यह अब मेरे साथ होता है कि जब आप एक पैकेज स्थापित करते हैं तो यह npm / यार्न डिफ़ॉल्ट रूप से होता है; वे नवीनतम प्रमुख.नॉर्मर संस्करण पाते हैं और ^ मेज.मिनोर.0 को पैकेज में निर्दिष्ट करते हैं। आगजनी, जो अप्रत्याशित रूप से प्रमुख संस्करण के उन्नयन को रोकता है, तब भी जब अपग्रेड-टू-लेटेस्ट को स्पष्ट रूप से अनुरोध किया जाता है। मुझे आश्चर्य है कि अगर पिपेनव को ऐसा करना चाहिए - लेकिन यह एक अलग मुद्दा होगा।

हाँ, मैं https://github.com/pypa/pipenv/issues/966#issuecomment -408420493 में जो सुझाव देना चाह रहा था, उसकी तर्ज पर

यह सुनने के लिए बहुत उत्साहित हैं कि इस पर काम किया जा रहा है!

इस समय के दौरान, क्या किसी को सुझाया गया वर्कअराउंड है कि pipenv lock चलने से कम श्रमसाध्य और त्रुटि-प्रवण है और इसके परिणामस्वरूप लॉकफ़ाइल परिवर्तन जो मैं लागू नहीं करना चाहता हूँ?

@benkuhn ऐसा नहीं है कि मुझे पता है - मैं हर समय एक ही लॉक और रिवर्ट डांस करता हूं।

आह ठीक है, आप कम से कम कभी-कभी हाथ से बचने से बच सकते हैं:

1. pipenv lock
2. git commit -m "FIXME: revert"
3. pipenv install packagename
4. git commit -m 'Add dependency on packagename'
5. git rebase -i
6. FIXME: revert कमिट करें

दुर्भाग्य से यह अभी भी एक असंगत Pipfile.lock बनाने के लिए संभव है अगर आपका Pipfile.lock एक पैकेज के संस्करण से शुरू होता है जो packagename की आवश्यकताओं को पूरा करने के लिए बहुत पुराना है, लेकिन शायद pipenv शिकायत करेगा इसके बारे में अगर ऐसा होता है?

--keep-outdated व्यवस्थित रूप से केवल स्पष्ट निर्भरता को पुराना रखने के लिए लगता है जो Pipfile में निर्दिष्ट (अनपिन किए गए) हैं, जबकि सभी अंतर्निहित निर्भरताएँ अपडेट की गई हैं।

क्या मैं सही हूं कि अन्य निर्भरता को अपडेट किए बिना pipenv==2018.7.1 का उपयोग करके एकल निर्भरता को अपडेट / स्थापित करना संभव नहीं है? मैंने बिना किसी सफलता के --selective-upgrade और --keep-outdated विभिन्न संयोजनों की कोशिश की।

Pipfile.lock को मैन्युअल रूप से संपादित करना कोई मज़ा नहीं है ...

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

बेशक, ### यदि अपडेट अनिवार्य है, तो सभी आवश्यक निर्भरता को अपडेट करना ठीक है, लेकिन सिर्फ उन लोगों के बजाय सभी आउटडेटेड नहीं हैं।

इसके अलावा विकल्प --selective-upgrade और --keep-outdated लिए क्या उपयोगी हैं, यह स्पष्ट नहीं है, यहाँ एक और मुद्दा है इस # 1554 पर प्रकाश डाला गया है, और कोई भी इन विकल्पों का जवाब देने में सक्षम नहीं है, अविश्वसनीय।

लेकिन मेरी बड़ी निराशाजनक बात यह है कि पायथन आधिकारिक दस्तावेज द्वारा ही इस पैकेज की pip साथ रहें, जो इन मुद्दों को भी हल नहीं करता है, लेकिन कम से कम यह बहुत ही न्यूनतम है और यह ज्यादातर किसी भी वातावरण में शामिल है (अतिरिक्त निर्भरता नहीं जोड़ता है)।

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

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

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

लेकिन चीजें अभी सबसे खराब हो जाती हैं, और मैं जो कहने जा रहा हूं वह एक राय नहीं है, यह एक सच्चाई है।

एक निर्भरता को जोड़ने की कोशिश करने के बाद, जिसे मैंने इस मुद्दे से निपटने से बचने के लिए खारिज कर दिया (क्योंकि यह एक देव निर्भरता है, इसलिए मैंने pip और पुराने requirements-dev.txt दृष्टिकोण के साथ एक दूसरा वातावरण बनाया, बस उस उपकरण), मुझे एक और निर्भरता जोड़ने की जरूरत है।

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

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

मैंने महीनों तक इस धागे का पालन किया है, और मुझे लगता है कि कोई भी वास्तविक परियोजना अंततः इस मुद्दे पर ठोकर खाएगी, क्योंकि व्यवहार अप्रत्याशित, प्रति-सहज ज्ञान युक्त और हां: खतरनाक है।

लगभग एक महीने पहले मैंने pipenv , poetry अधिक व्यापक विकल्प आज़माया; इसने समस्याओं को हल किया _ __ हल करने के लिए आवश्यक:
1) निर्भरता के एक सेट का प्रबंधन (setup.py, setup.cfg, pip, और pipfile -> pyproject.tomx)
2) भविष्य उन्मुख, पीछे की ओर संगत (फिर से pyproject.toml )
3) काफी गैर-राय ( मैं वास्तव में redis स्थापित करने के लिए नहीं कह रहा हूं )
4) और क्लासिक पिपेनव समस्या का समाधान: "इसके अलावा, आपको स्पष्ट रूप से यह बताना होगा कि जब आप नए स्थापित करते हैं तो लॉक किए गए पैकेजों को अपडेट न करें। यह डिफ़ॉल्ट होना चाहिए।" [[१] ((https://github.com/sdispater/poetry#what-about-pipenv)] [[२] ((https://github.com/pypa/pipenv/issues/966#uuecomment-339117289)]

मैंने pipenv मुद्दे पर इन विचारों को साझा किया, लेकिन जैसा कि @uranusjr ने कहा, "कोई भी किसी पर पिपेनव को मजबूर नहीं कर रहा है", और मैं कविता के लिए मजबूर नहीं कर रहा हूं। मुझे यह पसंद है, यह अच्छी तरह से काम करता है, और यह मेरी समस्याओं को हल करता है, लेकिन मैं सिर्फ समस्या का एक वैकल्पिक, अधिक-व्यापक समाधान साझा कर रहा हूं। बस वह सब मेरे 2 that के रूप में ले लो।

• अस्वीकरण के रूप में, मैं कविता टीम का सदस्य

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

कोई भी आपको हमारे इश्यू ट्रैकर में भाग लेने के लिए मजबूर नहीं कर रहा है; यदि आपके पास कोई उत्पादक टिप्पणी नहीं है, तो कृपया एक ऐसा मंच खोजें, जो समस्याओं को हल करने के लिए नहीं है।

उन उपयोगकर्ताओं के लिए जो वैकल्पिक रिज़ॉल्वर @uranusjr को आज़माने में रुचि रखते हैं और स्वयं कई हफ्तों से लागू कर रहे हैं, कृपया https://github.com/sarugaku/passa को आज़माएं जो संगत लॉकफ़ाइल्स उत्पन्न करेगा। कविता कई अलग-अलग चीजें करती है, लेकिन इसकी सीमाएं और मुद्दे भी हैं, और हमारे पास गुंजाइश के बारे में एक डिजाइन दर्शन असहमति है।

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

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

छोटी अवधि में मुझे लगता है कि अगर हम पहले से अधिक कटौती नहीं करते हैं तो हम पाइपनव में इसके लिए एक बैंड सहायता प्राप्त कर सकते हैं।

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

@techalchemy

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

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

इसकी अपनी सीमाएँ और मुद्दे भी हैं

कौन सा? पोएट्री का उपयोग करते समय आपके द्वारा सामना किए गए मुद्दों या सीमाओं के बारे में मैं वास्तव में उत्सुक हूं।

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

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

मैं यहाँ दो मजबूत विषय हैं:

• क्या आपको अपनी सभी पुरानी निर्भरताओं को अपडेट करना चाहिए, जहां आप एक नई निर्भरता स्थापित करने का प्रयास कर रहे हैं: जिन्हें अपडेट करने की आवश्यकता नहीं है क्योंकि जो नया पैकेज / संस्करण हम स्थापित करने का प्रयास कर रहे हैं, वह अस्तित्व निर्भरता के साथ काम कर सकता है, और यहां तक ​​कि वे भी नए पैकेज की टी निर्भरता हम स्थापित करने की कोशिश कर रहे हैं? हो सकता है कि यह इस टिकट के दायरे से बाहर हो, लेकिन यह एक बहुत महत्वपूर्ण विषय है।
• क्या इनमें से कोई एक पैरामीटर --keep-outdated --selective-upgrade हमें इन व्यवहारों से बचने की अनुमति देता है? यह स्पष्ट नहीं है कि ये विकल्प क्या करते हैं, उनके बारे में प्रलेखन की कमी है, और संबंधित मुद्दे (# 1554) में भी कोई भी इसका जवाब नहीं दे रहा है।

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

एक समान परिदृश्य के साथ तुलना करने के लिए, कल्पना करें कि आप अपने सिस्टम में vim टूल को स्थापित करने के लिए apt-get install vim निष्पादित करते हैं (और यदि लागू हो तो आवश्यक विम की निर्भरता या अपडेट), लेकिन यह भी कल्पना करें कि इस स्थिति में apt आपके सिस्टम की अन्य सभी निर्भरताओं को अपडेट करता है: अजगर, क्यूटी सिस्टम, लिनक्स कर्नेल ... और इसी तरह। ऐसा नहीं है कि उपयुक्त हमें अन्य निर्भरता को अपडेट करने की अनुमति नहीं देनी चाहिए, लेकिन ऐसा करने के लिए एक स्पष्ट आदेश है: apt-get upgrade , जबकि apt-get install PACKAGE केवल पैकेज स्थापित करें / अपडेट करें और यह निर्भरताएं हैं।

@sdispater भेद उस https://caremad.io/posts/2013/07/setup-vs-requirement/ या एक अच्छे स्थान पर इंगित करूंगा अमृत ​​उपयोग मामले के लिए लेख: http://blog.plataformatec.com.br/2016/07/understanding-deps-and-applications-in-your-mixfile/

pyproject.toml वास्तव में लाइब्रेरी परिभाषा मेटाडेटा के लिए समर्थित नहीं है - और पाइप के किसी भी संस्करण द्वारा बिल्कुल भी नहीं जो 517 और 518 को लागू नहीं करता है (दोनों जिनमें अभी भी कार्यान्वयन विवरण हैं) ने एक आधिकारिक के रूप में काम किया है पुस्तकालय घोषणा फ़ाइल। setup.cfg उस उद्देश्य के लिए मौजूद है (वास्तविक उत्तराधिकारी setup.py ) और IMHO दोनों का वास्तव में समर्थन किया जाना चाहिए। एक पुस्तकालय प्रकाशित है और अमूर्त निर्भरता के साथ उपभोग के लिए इरादा है ताकि वे दूसरों के साथ सैंडबॉक्स में अच्छा खेल सकें; आवेदन आमतौर पर बड़े, जटिल जानवर होते हैं जिनमें कभी-कभी सैकड़ों प्रत्यक्ष निर्भरताएं होती हैं। इसलिए हमारी एक मुख्य बात यह है कि जब हम अपने टूलींग को डिज़ाइन और निर्माण करते हैं, तो हम इसे भी ध्यान में रखते हैं

@mrsarm आपके पहले प्रश्न के लिए, अपडेट व्यवहार जानबूझकर किया गया था (और उस समय, / cc @ncoghlan और OWASP सुरक्षा चिंताओं से संबंधित) पर बड़े पैमाने पर चर्चा की गई थी। दूसरे बिंदु पर, व्यवहार वर्तमान में ठीक से लागू नहीं किया गया है, यही वजह है कि मुद्दा अभी भी खोला गया है, जिसने हमें पिपेनव के पीछे समर्थन करने वाले रिवाल्वर को फिर से लिखना शुरू कर दिया, जिसका मैंने ऊपर उल्लेख किया था। इसने इस व्यवहार का समर्थन नहीं किया। --selective-upgrade को केवल उन चीजों को चुनिंदा रूप से अपग्रेड करने के लिए माना जाता है जो नए पैकेज की निर्भरता हैं, जबकि --keep-outdated कुछ भी वापस पकड़ लेंगे जो नए पैकेज द्वारा आवश्यक निर्भरता को संतुष्ट करते हैं। थोड़ा अलग है, लेकिन मुझे पूरा यकीन है कि न तो अभी सही ढंग से काम करता है।

pyproject.toml वास्तव में लाइब्रेरी की परिभाषा मेटाडेटा के लिए समर्थित नहीं है - और पाइप्स के किसी भी संस्करण द्वारा बिल्कुल भी नहीं जो कि 517 और 518 को लागू नहीं करता है (दोनों जिनमें से अभी भी कार्यान्वयन विवरण काम कर रहे हैं) एक आधिकारिक पुस्तकालय घोषणा फ़ाइल के रूप में । setup.cfg उस उद्देश्य (setup.py के लिए वास्तविक उत्तराधिकारी) के लिए मौजूद है और IMHO उन दोनों को वास्तव में समर्थित होना चाहिए।

खैर यह निश्चित रूप से विषय है, लेकिन यह एक महत्वपूर्ण चर्चा है इसलिए मैं खुद की मदद नहीं कर सकता।

वास्तव में setup.cfg आसपास कोई मानक नहीं है जो अभी डिस्टुटिल्स और सेटपूल द्वारा स्थापित सम्मेलनों के अलावा है। pyproject.toml पुस्तकालय मेटाडेटा के लिए बिल्कुल setup.py के उत्तराधिकारी के रूप में है या समुदाय ने setup.cfg में आवश्यकताओं को रखा होगा।

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

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

अजगर के साथ और अन्य पारिस्थितिकी प्रणालियों के साथ मेरे अनुभव में एक आवेदन और एक पुस्तकालय के बीच एकमात्र सही अंतर यह है कि क्या आप लॉकफ़ाइल का उपयोग कर रहे हैं या नहीं। बेशक वहाँ एक तीसरा मामला है जहाँ आप वास्तव में एक requirements.txt या Pipfile और कोई वास्तविक कोड नहीं चाहते हैं और ऐसा लगता है कि सभी पाइपेंव ने अभी तक ( pipenv install -e . पर ध्यान केंद्रित किया है पाइपनव के रूप में इस श्रेणी में अभी भी पैकेज मेटाडाटा की कोशिश करने और समर्थन करने से डरता है)। दुर्भाग्य से, जबकि पिपेनव का डिज़ाइन इस दृष्टिकोण के साथ क्लीनर है, यह अधिकांश अनुप्रयोगों के लिए कम उपयोगी है, क्योंकि PEP 518 ने परियोजनाओं को संपादन योग्य मोड में कैसे स्थापित किया जाए, इसलिए पिपेनव का उपयोग करना जारी रखने के लिए हम सेटलाइट्स पर काफी फंस जाएंगे। जब तक आप सेटफ़ूल से दूर जाने के लिए pyproject.toml का उपयोग नहीं कर सकते हैं और अभी भी pipenv install -e . ।

वास्तव में setup.cfg के आस-पास कोई मानक नहीं है। अभी डिस्टिल और सेटप्टूल द्वारा स्थापित सम्मेलनों के अलावा। pyproject.toml पूरी तरह से लाइब्रेरी मेटाडेटा के लिए है जो कि setup.py के उत्तराधिकारी के रूप में है या समुदाय ने इसके बजाय setup.cfg में बिल्ड आवश्यकताओं को रखा होगा।

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

समुदाय ने इसके बजाय setup.cfg में निर्माण आवश्यकताओं को रखा होगा।

क्या आपका मतलब पेप लेखक हैं? आप उनसे पूछ सकते हैं कि उन्होंने अपना निर्णय क्यों लिया, वे इसे सभी को रेखांकित करते हैं।

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

यह हाल ही में मेलिंग सूची में आया था - कहीं भी कुछ भी नहीं मानक pyproject.toml आसपास की घोषणा की है कि इसके अलावा यह प्रणाली की आवश्यकताओं की घोषणा करने के लिए इस्तेमाल किया जाएगा। कुछ भी एक धारणा है; आप उस "लाइब्रेरी परिभाषा मेटाडेटा" को कॉल कर सकते हैं, लेकिन यह नहीं है। केवल अपनी परियोजना के बारे में कोई अतिरिक्त जानकारी (यानी कोई pep-345 अनुरूप मेटाडेटा) के साथ एक बिल्ड सिस्टम को परिभाषित करने का प्रयास करें और इसे pypi पर अपलोड करें और मुझे बताएं कि यह कैसे जाता है।

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

कौन कह रहा है कि आवेदनों को प्रवेश बिंदु की आवश्यकता नहीं है? पिपेनव के पास इसे संभालने का पूरा निर्माण है।

इसलिए पिपेनव का उपयोग जारी रखने के लिए हम सेटपूलों पर काफी समय तक अटके रहेंगे, क्योंकि आप सेटपूल से दूर जाने के लिए pyproject.toml का उपयोग नहीं कर सकते हैं और फिर भी पिपेनव इंस्टॉल-ई का उपयोग कर सकते हैं।

यहाँ का पालन नहीं ... हम हमेशा के लिए संस्करण 10 पर पाइप प्रतिशोधित नहीं छोड़ने जा रहे हैं, मैं सचमुच हमारे नए रिज़ॉल्वर का वर्णन कर रहा हूं, और वास्तविक इंस्टॉलर बस सीधे पाइप करने के लिए वापस आता है ... यह लोगों को संपादन योग्य उपयोग करने से कैसे रोकता है स्थापित करता है?

यह हाल ही में मेलिंग सूची पर आया था - कहीं भी कुछ भी pyproject.toml आसपास एक मानक घोषित नहीं किया गया है

यह सही है, यह एक "मानक" नहीं है, फिर भी उसी सूत्र में यह मान्यता है कि pyproject.toml को कॉल करके उन्होंने लोगों से इस फाइल को अन्य प्रोजेक्ट संबंधित सेटिंग्स / कॉन्फिगरेशन के लिए उपयोग करने के लिए कहा।

तो उसी तर्क से आपने यहाँ आह्वान किया:

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

pyproject.toml एक मानक है, और समुदाय ने इसे निर्माण प्रणाली, और पायथन परियोजना के अन्य भागों से संबंधित जानकारी रखने के लिए मानक स्थान के रूप में अपनाया है।

यहाँ का पालन नहीं ... हम हमेशा के लिए संस्करण 10 पर पाइप प्रतिशोधित नहीं छोड़ने जा रहे हैं, मैं सचमुच हमारे नए रिज़ॉल्वर का वर्णन कर रहा हूं, और वास्तविक इंस्टॉलर बस सीधे पाइप करने के लिए वापस आता है ... यह लोगों को संपादन योग्य उपयोग करने से कैसे रोकता है स्थापित करता है?

PEP 517 संपादन योग्य इंस्टॉल्स पर पिन किया गया ... जिसका अर्थ है कि अगर आप सेटअप टूल का उपयोग नहीं कर रहे हैं, जो संपादन मोड में प्रोजेक्ट स्थापित करता है (जो एक अवधारणा विकसित मोड के रूप में जाना जाता है) का उपयोग नहीं कर रहा है, तो संपादन योग्य मोड में प्रोजेक्ट स्थापित करने का कोई मानक तरीका नहीं है।

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

हाँ, बिल्ड सिस्टम को PEP 345 में वर्णित PKG-INFO फ़ाइल को आउटपुट करने की उम्मीद है। यह एक स्थानांतरण प्रारूप है जो एक sdist या व्हील में जाता है और इसे setup.py/setup.cfg से जनरेट किया जाता है, यह कोई प्रतिस्थापन नहीं है उपयोगकर्ता-सामना मेटाडेटा के लिए इस तरह। PEP 518 का pyproject.toml का उपयोग एक निर्माण प्रणाली के रूप में डिस्टुटिल्स / सेटप्टूल के विकल्प का समर्थन करने के बारे में है, कोई भी अभी sdist / व्हील प्रारूपों को बदलने की कोशिश नहीं कर रहा है। उन प्रतिस्थापन बिल्ड सिस्टम को अपने मेटाडेटा को रखने के लिए जगह की आवश्यकता होती है और सौभाग्य से PEP 517 ने ऐसा करने के लिए इन प्रणालियों के लिए tool. नाम स्थान आरक्षित किया। यह एक धारणा नहीं है - "लाइब्रेरी डेफिनिशन मेटाडेटा" के लिए फ्लिट और कविता दोनों ने इस नाम स्थान को अपनाया है।

केवल अपनी परियोजना के बारे में कोई अतिरिक्त जानकारी (यानी कोई pep-345 अनुरूप मेटाडेटा) के साथ एक बिल्ड सिस्टम को परिभाषित करने का प्रयास करें और इसे pypi पर अपलोड करें और मुझे बताएं कि यह कैसे जाता है।

कितना रचनात्मक।

कौन कह रहा है कि आवेदनों को प्रवेश बिंदु की आवश्यकता नहीं है? पिपेनव के पास इसे संभालने का पूरा निर्माण है।

यह निर्माण कहां है? मैं https://pipenv.readthedocs.io/en/latest/ पर पिपेनव दस्तावेज के किसी भी पृष्ठ पर "प्रविष्टि" शब्द भी नहीं पा सकता हूं, इसलिए "एक संपूर्ण निर्माण" बहुत दूर लगता है? यदि आप संपादन योग्य इंस्टॉलेशन से मतलब रखते हैं तो हम उस बिंदु पर पहुंच गए हैं जो मैं ऊपर बना रहा था - पिपेनव ने खुद को pipenv install -e . में हुक करने का एकमात्र तरीका और पैकेज के रूप में एक एप्लिकेशन को विकसित करने का निर्णय लिया है, जो भविष्य में आने वाले फॉरनव के समर्थन के लिए है। यहाँ सेटपूलों को युग्मित किया जाता है। मुझे लगता है कि पूरा विवाद वास्तव में इस मुद्दे पर उबलता है और लोग (निश्चित रूप से मुझे) निराश होते हैं कि हम अब पुस्तकालयों को परिभाषित कर सकते हैं जो सेटपूल का उपयोग नहीं करते हैं, लेकिन पिपेनव के साथ उन पर विकसित नहीं हो सकते हैं। यह पूरी तरह से स्पष्ट होने के लिए पिपेनव की गलती नहीं है (PEP 518 ने संपादन योग्य इंस्टॉल्स पर पंट करने का फैसला किया है), लेकिन इस मुद्दे को स्वीकार करने से इनकार करने से प्रवचन में निराशा हुई है क्योंकि कविता एक विकल्प प्रदान करती है जो इस मुद्दे को एक तरह से संभालती है जो कि अनुरूप है pyproject.toml प्रारूप के साथ। पिपेनव कहता रहता है कि कविता बुरे निर्णय लेती है लेकिन वास्तव में आगे का मार्ग प्रदान करने का प्रयास नहीं करती है।

https://pipenv.readthedocs.io/en/latest/advanced/#custom-script- शॉर्टकट

कृपया दस्तावेज़ पढ़ें।

@bertjwregeer :

pyproject.toml एक मानक है, और समुदाय ने इसे निर्माण प्रणाली, और पायथन परियोजना के अन्य भागों से संबंधित जानकारी रखने के लिए मानक स्थान के रूप में अपनाया है।

महान, और हम इस प्रणाली का उपयोग करके निर्मित sdists और पहियों को समायोजित करने के लिए खुश हैं और जब तक संपादन योग्य स्थापित करने के लिए एक मानक नहीं है तब तक हम sdists और पहियों का निर्माण करने के लिए पाइप का उपयोग करना जारी रखेंगे और निर्भरता संकल्प को संभालेंगे। कृपया मेरी प्रतिक्रियाओं को पूरा पढ़ें। पाइप के लेखक और अनुरक्षक, प्रश्न में पेप्स के, और खुद को और

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

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

https://pipenv.readthedocs.io/en/latest/advanced/#custom-script- शॉर्टकट
कृपया दस्तावेज़ पढ़ें।

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

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

तो हाँ, कृपया अपनी विषाक्तता कहीं और ले जाएं। आपके रवैये का यहाँ स्वागत नहीं है। आखरी चेतावनी। संघर्ष को भड़काने के लगातार प्रयास बर्दाश्त नहीं किए जाएंगे।