Pipenv: setup.py install_requires और Pipfile को सिंक में कैसे रखें

क्या पिपेनव में एक अजगर एपीआई है जिसका उपयोग किया जा सकता है? जब मैं किसी प्रोजेक्ट पर काम करता हूं तो मैं सूची को मैन्युअल रूप से अपडेट करता हूं लेकिन निम्नलिखित अच्छा हो सकता है:

from setuptools import setup
from pipenv import find_install_requires

setup(
    # ...
    install_requires=find_install_requires()
    # ...
)

फ़ंक्शन को केवल pipfiles [packages] अनुभाग में चाबियों की एक सूची वापस करने की आवश्यकता है। मुझे लगता है कि आप पहले से ही एक सहायक फ़ंक्शन का उपयोग करके इस कार्यक्षमता को प्राप्त कर सकते हैं, लेकिन यह अच्छा होगा यदि यह पिपेनव का हिस्सा था, इसलिए हम सभी को इसे लागू करने की आवश्यकता नहीं है।

पिपफाइल , पिपेनव के पिपफाइल पार्सिंग का समर्थन करने वाला कार्यान्वयन, इसमें मदद कर सकता है:

import pipfile
pf = pipfile.load('LOCATION_OF_PIPFILE')
print(pf.data['default'])

लेकिन मैं इसकी अनुशंसा नहीं करता, या setup.py में Pipenv के आधार पर। pipenv (या pipfile ) आयात करने का मतलब है कि उपयोगकर्ता को वास्तव में आपके पैकेज को स्थापित करने का प्रयास करने से पहले इसे स्थापित करने की आवश्यकता है, और पिपेनव जैसे उपकरण बिना इंस्टॉल किए इसमें झांकने की कोशिश कर रहे हैं ( setup.py egg_info ) जीता काम नहीं। Setup.py केवल Setuptools पर निर्भर होना चाहिए।

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

हाँ अच्छा बिंदु मुझे अनदेखा करें।
शायद "पिपेनव इंस्टॉल" सिंक कर सकता है?

सोम, 8 जनवरी 2018 को शाम 5:04 बजे, त्ज़ु-पिंग चुंग नोटिफिकेशन @github.com
लिखा था:

Pipfile https://github.com/pypa/pipfile , कार्यान्वयन का समर्थन करता है
पार्सिंग, इसमें मदद कर सकता है:

पाइपफाइल आयात करें
pf = pipfile.load ('LOCATION_OF_PIPFILE')
प्रिंट (पीएफ। डेटा ['डिफ़ॉल्ट'])

लेकिन मैं इसकी अनुशंसा नहीं करता, या setup.py में Pipenv के आधार पर।
pipenv (या pipfile) आयात करने का अर्थ है कि उपयोगकर्ता को वास्तव में स्थापित करने की आवश्यकता है
कि अपने पैकेज को स्थापित करने का प्रयास करने से पहले, और पिपेनव जैसे उपकरण कोशिश कर रहे हैं
इंस्टॉल किए बिना इसमें झांकें (setup.py Egg_info) काम नहीं करेगा।
setup.py केवल Setuptools पर निर्भर होना चाहिए।

एक मध्यम जमीनी समाधान बम्पवर्सन के समान एक उपकरण लिखना होगा
https://github.com/peritus/bumpversion जो स्वचालित रूप से एक टेक्स्ट को सिंक करता है
पिपफाइल पर आधारित फाइल। इस फ़ाइल को अपने पैकेज के साथ वितरित करें, और इसे पढ़ें
setup.py में फिर यह सुनिश्चित करने के लिए सीआई या प्रतिबद्ध हुक का उपयोग करें कि फाइलें हमेशा हैं
मेल में।

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

@uranusjr यहां मेरी धारणाओं का परीक्षण कर रहा है, लेकिन क्या यह संभव नहीं होगा कि pipenv को setup.py के setup_requires में जोड़ा जाए, और एक setuptools कमांड में pipenv आयात में देरी हो? या इसे बुरा अभ्यास माना जाता है?

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

तो इसका क्या समाधान है जिसके कारण यह मुद्दा बंद हो गया? क्या Pipfile और setup.py में दोनों निर्भरताओं का ट्रैक रखने का कोई साधन नहीं है? क्या कोई सर्वोत्तम अभ्यास है जो इस मुद्दे को रोकता है?

इंस्टॉलर में तैनात या वितरित किए गए अनुप्रयोगों के लिए, मैं सिर्फ पिपफाइल का उपयोग करता हूं।

सेटअप के साथ पैकेज के रूप में वितरित किए गए अनुप्रयोगों के लिए, मैंने अपनी सभी निर्भरताओं को install_requires में रखा है।

फिर मैं pipenv install '-e .' चलाकर अपना पिपफाइल setup.py पर निर्भर करता हूं।

[अद्यतन 2019-08-23] मैं आजकल पिपफाइल में देव पैकेज रखता हूं, केवल रनटाइम निर्भरता को setup.py में रहने के लिए मिलता है।

मुझे लगता है कि @ कोरिजन का दृष्टिकोण यहां सबसे अच्छा अभ्यास है। पिपफाइल (और आवश्यकताएँ। txt) अनुप्रयोगों के लिए है; setup.py संकुल के लिए है। वे विभिन्न उद्देश्यों की पूर्ति करते हैं। अगर आपको उन्हें सिंक करने की ज़रूरत है, तो आप इसे गलत कर रहे हैं (आईएमओ)।

@uranusjr दस्तावेज़ीकरण के अनुसार नहीं।

पिपेनव एक उपकरण है जिसका उद्देश्य सभी पैकेजिंग दुनिया (बंडलर, कंपोजर, एनपीएम, कार्गो, यार्न, आदि) को पायथन दुनिया में लाना है। विंडोज़ हमारी दुनिया में प्रथम श्रेणी का नागरिक है।

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

शायद मैं समझ नहीं पा रहा हूँ। क्या आप कृपया अपने बयान पर विस्तार से बता सकते हैं?

जिस तरह से मैंने इसे समझा, वह यह है कि pipenv PHP के लिए कंपोजर के समान एक पूर्ण निर्भरता प्रबंधन प्रणाली है, लेकिन मुझे एहसास होने लगा है कि यह नहीं है। विशेष रूप से pipenv एक निर्भरता की निर्भरता को स्थापित नहीं करेगा जिसमें एक Pipfile और Pipfile.lock है, लेकिन setup.py में कोई install_requirements नहीं है।

@vascowhite जो सवाल आप पूछ रहे हैं वह पिपेनव के बारे में नहीं है बल्कि पाइथन पैकेजिंग टूल्स के बीच मौलिक अलगाव के बारे में है। पायथन वर्कफ़्लो में, setup.py फ़ाइलों का उपयोग वितरण योग्य पैकेज की स्थापना निर्भरता घोषित करने के लिए किया जाता है। इसलिए, अगर मेरे पास requests जैसा पैकेज है, और यह उन लोगों पर निर्भर करता है जिनके पास cffi स्थापित है, तो मैं इसे अपने setup.py में घोषित करूंगा ताकि जब लोग pip install requests चलाएं

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

इसलिए यदि आप जानना चाहते हैं कि पिपफाइल्स को पुनरावर्ती रूप से हल क्यों नहीं किया जाता है, तो ऐसा इसलिए है क्योंकि ऐसा नहीं है कि उनका उपयोग पायथन में कैसे किया जाता है। pipenv install को चलाने के लिए अंततः एक लक्ष्य की आवश्यकता होती है जो setuptools द्वारा स्थापित किया जा सकता है, जिसका अर्थ है कि इसकी स्थापना आवश्यकताओं को इसकी सेटअप फ़ाइल में परिभाषित किया जाएगा।

@techalchemy मैं आपके पॉप अप करने से पहले इसी तरह की प्रतिक्रिया के माध्यम से आधा रास्ता था (सब कुछ हटा दें)

मैं यह भी नोट करना चाहूंगा कि @vascowhite जो आप पूछ रहे हैं वह वास्तव में विचित्र नहीं है। पिपफाइल और लॉक फाइल दोनों उपलब्ध होने के साथ, दो अलग-अलग वर्कफ़्लो को समेटना संभव है। एक आदर्श दुनिया में, पिपफाइल setup.py के install_requires को बदल देता है, और वर्चुअल निर्भरता को निर्दिष्ट करने के लिए उपयोग किया जाता है, जबकि लॉक फ़ाइल का उपयोग इसके आधार पर एक ठोस निर्भरता सेट बनाने के लिए किया जाता है, जो आवश्यकताएँ.txt को बदल देता है।

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

हालांकि आशा नहीं खोई है (कम से कम मेरी नहीं)। इस मुद्दे के इर्द-गिर्द बहुत सारे पीईपी प्रस्तावित और कार्यान्वित किए जा रहे हैं, और मुझे लगता है कि सेटअप.py और आवश्यकताएँ.txt दोनों के साथ चीजें सही रास्ते पर हैं, दोनों एक कठोर, घोषणात्मक प्रारूप की ओर बढ़ रहे हैं। इतने बड़े पारिस्थितिकी तंत्र के साथ, चीजों को धीरे-धीरे आगे बढ़ने की जरूरत है (या पायथन 3.0 देखें), लेकिन वास्तव में आगे बढ़ रहे हैं।

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

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

यदि आप ऊपर बताई गई मेरी सलाह पर कायम रहते हैं, तो आप setup.py और pipenv दोनों में पूरी तरह से सामंजस्य स्थापित कर सकते हैं। सब उतावले होने की जरूरत नहीं है। :)

ऐसा लगता है कि भ्रमित करने वाला मैं अकेला नहीं हूँ #1398

हालांकि मैं जितना कर सकता था उससे कहीं ज्यादा बेहतर रखो :)

एक setup.py $ के साथ pipenv का उपयोग करने के बारे में जानकारी के लिए यहां आए; चर्चा में मेरे .2 सेंट जोड़ना।

मेरे पास एक अजगर पैकेज है जो setup.py जैसा दिखता है:

 setup(                                                                                                     
    name='my-pkg-name',                                                                             
    packages=find_packages(),                                                                              
    install_requires=[...],
    extras_require={
        'develop': ['click']
    },
    entry_points={
        'console_scripts': [
            'my-pkg-name-cmdline = my-pkg-name.cli:tool'
        ]
    }

जैसा कि आप देख सकते हैं कि मैं निर्माण और परिनियोजन जैसे कार्यों के लिए स्क्रिप्ट एंट्रीपॉइंट में click का उपयोग करता हूं।

जब मैं $ my-pkg-name-cmdline build चलाता हूं तो मुझे click इंस्टॉल नहीं मिलता, क्योंकि pipenv install --dev pipenv virtualenv में पैकेज इंस्टॉल करता है। मुझे इसे काम करने के लिए pipenv shell/exit के साथ फील करना होगा। ऐसा लगता है कि इस पर अभी भी कुछ खुरदुरे किनारे हैं।

इसलिए +1 पैकेज के लिए pipenv का उपयोग नहीं करने के लिए।

मुझे लगता है कि आपसे उस परिदृश्य में pipenv run my-pkg-name-cmdline build पर कॉल करने की अपेक्षा की जाती है।

@ कोरिजन मैं अभी भी सही वर्कफ़्लो के बारे में निश्चित नहीं हूं (अभी भी पिपेनव के साथ थोड़ा प्रयोग कर रहा हूं)।

अभी तक, मेरे लिए काम करने वाला कार्यप्रवाह है:

(starting from scratch)
1- pipenv --three
2- pipenv install [--dev]
3- pipenv install -e . (install application locally)
4- pipenv shell (to enter the virtualenv)

अब मैं कमांड लाइन से अपना पैकेज बिल्ड click स्क्रिप्ट चला सकता हूं।

अगर मैं स्थानीय रूप से (चरण 3) एप्लिकेशन इंस्टॉल करने से पहले वर्चुअलएन्व (चरण 4) में प्रवेश करता हूं, तो यह काम नहीं करता है।

शायद मुझे यह याद रखने के लिए अपने दिमाग को फिर से स्थापित करना होगा कि पैकेज pipenv shell से पहले स्थापित किए जाने चाहिए ( virtualenv का उपयोग करते समय आपको वर्चुअलएन्व सक्रिय के साथ पैकेज स्थापित करने की आवश्यकता होती है)।

@apiraino मुझे लगता है कि आपको यहीं चीज़ नहीं मिल रही है। यदि आप अपने पैकेज में क्लिक (आयात) का उपयोग करना चाहते हैं, तो आपको इसे इसके बजाय install_requires में रखना चाहिए, ताकि आपके पैकेज को स्थापित करने वाले लोग (स्वयं सहित) क्लिक भी इंस्टॉल कर सकें। इसे extras_require['dev'] में डालने का मतलब है कि यह एक वैकल्पिक निर्भरता है, यानी आपका पैकेज इसके बिना काम कर सकता है, लेकिन उन अतिरिक्त को स्थापित करने से कुछ अतिरिक्त सुविधाएं मिल सकती हैं।

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

@Korijn pipenv install '-e .' एक Pipfile $ उत्पन्न करता है जो setup.py में install_requires के तहत सूचीबद्ध मॉड्यूल को प्रतिबिंबित नहीं करता है

पिपेनव 9.0.3 के लिए अभी भी यही स्थिति है।

मैं अपने setup.py के install_requires से Pipfile कैसे उत्पन्न कर सकता हूं?

उद्धरण चिह्नों का प्रयोग न करें

मैंने उद्धरण चिह्नों का उपयोग करना बंद कर दिया। हालांकि, मुझे Pipfile नहीं बनाया गया है जिसमें install_requires अनुभाग से विवरण शामिल हैं setup.py ।

@बेंजामिनवेब मैं आज उसी चीज़ से भ्रमित था। हालाँकि, मुझे लगने लगा है कि वर्तमान व्यवहार सही हो सकता है।

@techalchemy ने ऊपर उल्लेख किया है कि

पिपफाइल में शीर्ष स्तर की आवश्यकताएं होती हैं और जहां संभव हो वहां अनपिन करना पसंद करते हैं। जब आप कोई पैकेज स्थापित करते हैं, तो उसकी setup.py की आवश्यकताओं को पुनरावर्ती रूप से सर्वोत्तम मिलान के लिए हल किया जाता है जो आपकी अन्य आवश्यकताओं को भी पूरा करता है।

यदि आप https://github.com/pypa/pipenv/issues/1263#issuecomment -362600555 में उल्लिखित वर्कफ़्लो का उपयोग करते हैं, जब आप किसी मौजूदा Pipfile के बिना किसी प्रोजेक्ट पर pipenv install '-e .' चलाते हैं, तो pipenv एक नया Pipfile उत्पन्न करता है निम्नलिखित:

[packages]

"e1839a8" = {path = ".", editable = true}

इस मामले में, वर्चुअलएन्व में स्थापित करने के लिए आपके द्वारा स्पष्ट रूप से अनुरोध किया गया एकमात्र पैकेज पैकेज ही है (यानी "।"), इसलिए यह समझ में आता है कि केवल "।" पिपफाइल में ( [packages] ) में जोड़ा जाता है। इसी तरह, यदि आप pipenv install requests , तो अनुरोधों के setup.py से install_requires निर्भरता में से कोई भी आपके प्रोजेक्ट के Pipfile में नहीं जोड़ा जाता है।

हालांकि, जब पैकेज स्थापना चरण आगे होता है, तो पैकेज के लिए निर्भरता समाधान के भाग के रूप में install_requires निर्भरताएं स्थापित की जाएंगी ।

ध्यान दें कि Pipfile के विपरीत, Pipfile.lock संपूर्ण वर्चुअलएन्व के लिए सभी सटीक निर्भरता को रिकॉर्ड करता है, जिसमें विशिष्ट संस्करणों के लिए लॉक की गई install_requires निर्भरता शामिल होती है। यदि आप Pipfile.lock को देखते हैं जो उत्पन्न होता है, तो आप install_requires निर्भरताएँ सूचीबद्ध देखेंगे।

यह संभव है कि मैं पूरी तरह गलत समझ रहा हूं कि यह कैसे काम करने की उम्मीद है। हो सकता है कि @techalchemy या @uranusjr इस बात की पुष्टि कर सकें कि क्या इस बारे में सोचने का यह सही तरीका है?

आपकी सोच मेरे से मेल खाती है। मैं यह भी उल्लेख करूंगा कि हाल ही में Setuptools उन्नति और Flit जैसे टूल के साथ आप अभी भी अपने पैकेज की निर्भरता को अच्छे TOML रूप में निर्दिष्ट कर सकते हैं (सेटअप में आवश्यकता स्ट्रिंग्स के बजाय, जो वास्तव में बहुत सुंदर नहीं है)। आप बस उन्हें पिपफाइल के बजाय pyproject.toml में निर्दिष्ट करें।

@uranusjr ऐसा लगता है कि आप जो कह रहे हैं वह यह है कि पिपफाइल को केवल परियोजना निर्भरताओं को स्पष्ट रूप से सूचीबद्ध करने की आवश्यकता है यदि उन्हें पहले से ही सेटअप टूल या फ्लिट (setup.py या pyproject.toml के माध्यम से) द्वारा कैप्चर नहीं किया जा रहा है।

उदाहरण के लिए, यदि setup.py ऐसा दिखता है:

install_requires=['A'],
extras_require={
    'dev': ['B'],
},

तब पिपफाइल को केवल निम्नलिखित की आवश्यकता होती है:

[[source]]

url = "https://pypi.python.org/simple"
verify_ssl = true
name = "pypi"


[packages]

"e1839a8" = {path = ".", editable = true}


[dev-packages]

"e1839a8" = {path = ".", extras = ["dev"], editable = true}

pipenv install चलाने से उत्पादन के लिए निर्भरता A स्थापित होगी, और pipenv install --dev विकास के लिए निर्भरता A और B स्थापित करेगी।

यदि कोई पहले से ही Setuptools या Flit का उपयोग कर रहा है, तो क्या कोई कारण है कि निर्भरता को [packages] या [dev-packages] के तहत Pipfile में जोड़ा जाना चाहिए? एक उदाहरण के रूप में अनुरोधों को देखते हुए, यह मेरे लिए स्पष्ट नहीं है कि क्यों विकास निर्भरताएं स्पष्ट रूप से [dev-packages] के तहत पिपफाइल में सूचीबद्ध हैं, लेकिन install_requires और test_requirements निर्भरता सभी सेटअप में कैप्चर की गई हैं .py.

ऐसा लगता है कि केवल यही कारण है कि आपको पिपफाइल पर निर्भरता को स्पष्ट रूप से जोड़ने की आवश्यकता होगी यदि आप सेटअपटूल या फ्लिट का उपयोग नहीं कर रहे हैं। क्या ये सही है? क्या इसके सच नहीं होने के कोई कारण हैं?

मुझे लगता है कि यह सिर्फ व्यक्तिगत पसंद है। देव निर्भरता को extras_require[dev] में सूचीबद्ध करना केवल एक परंपरा है; dev-packages OTHO एक सुपरिभाषित कुंजी है। extras_require[dev] किसी भी उपयोगकर्ता को pip install package[dev] में सक्षम करेगा, जो अनुरक्षकों को पसंद नहीं हो सकता है। मैं समझ सकता हूं कि लोग एक दूसरे को पसंद करते हैं।

packages के लिए, नहीं, वास्तव में ऐसा कोई परिदृश्य नहीं है जो install_requires IMO से अधिक समझ में आता है। मुझे यकीन है कि लोग रचनात्मक उपयोग के साथ आएंगे।

यह मुद्दा क्यों बंद है?

@JulienPalard यह कुछ कारणों से बंद है:

1. पिपफाइल और setup.py फाइलें वास्तव में सिंक में रखने के लिए नहीं हैं, प्रति से, मुझे लगता है कि विवरणों पर चर्चा करने वाले लेखों का एक समूह रहा है लेकिन टीएल; डॉ Pipfile मोटे तौर पर एक के बराबर है शीर्ष स्तर requirements.txt
2. यदि आप चाहते हैं कि आपका प्रोजेक्ट (मान लें कि यह वर्तमान निर्देशिका है) का setup.py प्रबंधित वर्चुअलएन्व में हल हो गया है, तो वर्कफ़्लो केवल pipenv install -e . होगा - यह आपके Pipfile में एक प्रविष्टि डालता है Pipfile.lock में हल किया गया install_requires सहित। यदि आप एक परिवर्तित install_requires के कारण वर्चुअलएन्व को नवीनतम सामग्री के साथ अपडेट करना चाहते हैं, तो आपको pipenv update चलाना होगा जो नवीनतम संस्करण में pipenv lock && pipenv sync के समान है।

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

वास्तव में वे Pipfile से अधिक समान हैं, $#$ requirements.txt $#$ के समान हैं: requirements.txt सभी पैकेजों को एक फ्लैट तरीके से निर्दिष्ट करता है जबकि Pipfile और setup.py केवल प्रवेश स्तर की निर्भरता की आवश्यकता है। Pipfile.lock और requirements.txt में समान जानकारी होती है।

मैंने एक POC सिंक स्क्रिप्ट बनाई जिसे आगे लागू किया जा सकता है लेकिन वर्तमान में हमारे उपयोग के मामले को कवर करता है:
https://gist.github.com/iddan/f190c3c7d54f4fc4655da95fb185e641

@iddan यह अनिवार्य रूप से मैं कह रहा हूं, इनमें से प्रत्येक चीज आपकी निर्भरताओं की शीर्ष स्तर की सूची का प्रतिनिधित्व करती है, लेकिन एक _एप्लिकेशन_ ( setup.py ) स्थापित करने के लिए है और दूसरा _ इसे विकसित करने के लिए है ( Pipfile )।

setup.py का उपयोग करने के पूर्व मामले में, आपके पास ओपन-एंडेड या पूरी तरह से पिन की गई निर्भरताओं को घोषित करने के लिए वही विकल्प हैं जैसे आप requirements.txt के साथ करेंगे, लेकिन अधिकांश लोग यहां ओपन-एंडेड निर्भरता पिनिंग का उपयोग करते हैं। Pipfile आप सख्त या ढीले पिन भी निर्दिष्ट कर सकते हैं, लेकिन इसी तरह इसे आपके निर्भरता ग्राफ की _unflattened_ सूची के रूप में रखने के लिए प्रोत्साहित किया जाता है। फिर से, मैं इस बात पर जोर देना चाहता हूं कि ये दोनों चीजें requirements.txt फाइलों में भी पूरी तरह से मान्य हैं, यही वजह है कि मैं अनुप्रयोगों और पुस्तकालयों के बीच जिम्मेदारियों को अलग करने पर लगातार जोर दे रहा हूं। आप हर बातचीत और हर ट्यूटोरियल में और पीपीए द्वारा डाले गए सभी मैसेजिंग में इस पर जोर देते हुए सुनेंगे।

Pipfile.lock और requirements.txt एक ही चीज़ नहीं हैं। आप एक Pipfile.lock requirements.txt उत्पन्न कर सकते हैं, लेकिन आप किसी मध्यस्थ Pipfile का उपयोग किए बिना किसी आवश्यकता फ़ाइल से सीधे लॉकफ़ाइल उत्पन्न नहीं कर सकते। ऐसा इसलिए है क्योंकि Pipfile.lock एक संक्रमणीय बंद का प्रतिनिधित्व करता है और निर्भरता समाधान करने के लिए हमेशा एक मध्यस्थ Pipfile की आवश्यकता होगी।

मूल प्रश्न के रूप में, एक संपादन योग्य पथ के रूप में प्रश्न में निर्देशिका को शामिल करने के अलावा setup.py फ़ाइल को Pipfile के साथ सिंक में रखने का कोई कारण नहीं है। जब आप pipenv lock चलाते हैं, तो setup.py फ़ाइल में निर्भरता स्वतः हल हो जाएगी। मैं आपके विशिष्ट उपयोग के मामले के बारे में निश्चित नहीं हूं, @iddan , या सेटअप फ़ाइल पर वापस चीजों को लिखने के लिए आपको एक विशेष पार्सर की आवश्यकता क्यों है, लेकिन मुझे संदेह है कि आप डोनाल्ड स्टफ के लेख को setup.py बनाम आवश्यकताओं पर पढ़ना चाह सकते हैं। txt या हमारे एक अनुरक्षक द्वारा इस टिप्पणी को संदर्भित करने के लिए कि भेद के बारे में और यह विशेष रूप से पिपेनव पर कैसे लागू होता है।

मेरा उपयोग मामला यह है कि के हेल्थ में हमारे आंतरिक पैकेज के साथ एक रेपो है जो स्टैंडअलोन सेवाएं हैं और पैकेज के रूप में भी उपभोग किया जा सकता है। इसलिए हम पैकेज उपभोक्ताओं और सेवा के देव/परिनियोजन कॉन्फ़िगरेशन के बीच अपनी शीर्ष स्तरीय निर्भरता साझा करना चाहते हैं। चूंकि हम अपनी निर्भरता को प्रबंधित करने के लिए पिपेनव का उपयोग कर रहे हैं, Pipfile setup.py रूप में प्राप्त करना अच्छा होगा

#2148 के एक प्रकार की तरह लगता है (requirements.txt को पिपफाइल के साथ बदलना)।

लेकिन यह setup.py . के बारे में है

इस। मुद्दा। चाहिए। नहीं। होना। बंद किया हुआ।

यह मुद्दा बंद है क्योंकि

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

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

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

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

एक काम करो और अच्छे से करो!

हेलो सब लोग,

@ कोरिजन मैंने उस हिस्से को पढ़ा जहां आप बता रहे थे कि आप पिपफाइल के साथ setup.py को सिंक करने के लिए extra_requires का उपयोग कैसे करते हैं।

मैं ऐसा करने की कोशिश कर रहा था और देखा कि Pipfile.lock में dev अनुभाग में extra_require संकुल नहीं है, इसलिए जब आपके पास एक खाली venv में स्रोत कोड है और pipenv install --dev करें , क्योंकि Pipfile.lock में extra_require आवश्यकताएँ नहीं हैं pipenv केवल संकुल को install_require पर संस्थापित करता है।

setup.py

import os  # noqa: D100
from setuptools import setup, find_packages


def read(fname):
    """Read a file and return its content."""
    with open(os.path.join(os.path.dirname(__file__), fname)) as f:
        return f.read()


setup(
    name='auditor_client',
    version='0.0.0',
    description='Auditor client package',
    long_description=read('README.md'),
    packages=find_packages(exclude=['tests']),
    install_requires=['requests==2.9.1'],
    extras_require={'dev': ['flake8', 'flake8-docstrings', 'pytest', 'coverage', 'tox']},
    setup_requires=["pytest-runner"],
    tests_require=["pytest"]
)

पिपफाइल

[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[packages]
"e1839a8" = {editable = true, path = "."}

[requires]
python_version = "3.6"

[dev-packages]
"e1839a8" = {editable = true, extras = ["dev"], path = "."}

पिपफाइल.लॉक

{
    "_meta": {
        "hash": {
            "sha256": "e58b833e497814c83a2f0b93ad21d33a2af8b72721b20e9607a6c9135978422d"
        },
        "pipfile-spec": 6,
        "requires": {
            "python_version": "3.6"
        },
        "sources": [
            {
                "name": "pypi",
                "url": "https://pypi.org/simple",
                "verify_ssl": true
            }
        ]
    },
    "default": {
        "e1839a8": {
            "editable": true,
            "path": "."
        },
        "requests": {
            "hashes": [
                "sha256:113fbba5531a9e34945b7d36b33a084e8ba5d0664b703c81a7c572d91919a5b8",
                "sha256:c577815dd00f1394203fc44eb979724b098f88264a9ef898ee45b8e5e9cf587f"
            ],
            "version": "==2.9.1"
        }
    },
    "develop": {
        "e1839a8": {
            "editable": true,
            "path": "."
        },
        "requests": {
            "hashes": [
                "sha256:113fbba5531a9e34945b7d36b33a084e8ba5d0664b703c81a7c572d91919a5b8",
                "sha256:c577815dd00f1394203fc44eb979724b098f88264a9ef898ee45b8e5e9cf587f"
            ],
            "version": "==2.9.1"
        }
    }
}

सही व्यवहार नहीं होना चाहिए कि Pipfile.lock ने extra_require dev संकुल को ट्रैक किया है?

हाँ, यह मेरे लिए एक बग/सीमा की तरह दिखता है। इसके लिए आपको एक अलग बग/मुद्दा दर्ज करना चाहिए।

मुझे लगता है कि इस समस्या के बारे में ट्रैकर में एक समस्या खुल गई है, हालांकि मैं अभी इसका पता नहीं लगा सकता। कृपया किसी एक को खोलने से पहले मौजूदा मुद्दों की खोज करें। अग्रिम में धन्यवाद :)

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

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

@techalchemy तो मैं इस मामले में अपनी देव निर्भरताओं का प्रबंधन कैसे कर सकता हूं? मैं केवल यह जानना चाहता हूं कि पिपेनव का अच्छे तरीके से उपयोग कैसे करें

मैं अपने स्वयं के प्रोजेक्ट के लिए इस बारे में सोच रहा था, और मुझे एहसास हुआ कि मुझे वास्तव में packages / dev-packages भेद की आवश्यकता नहीं है। {editable = true, extras = ["dev"], path = "."} को packages में सूचीबद्ध करने के बारे में कैसे।

इस पिपेनव-सेटअप पैकेज को देखें

यह pipfile/lockfile को setup.py . में सिंक करता है

$ pipenv-setup sync

package e1839a8 is local, omitted in setup.py
setup.py successfully updated
23 packages from Pipfile.lock synced to setup.py

आप विकास निर्भरताओं को अतिरिक्त आवश्यकताओं के साथ सिंक करने के लिए $ pipenv-setup sync --dev कर सकते हैं। या $ pipenv-setup sync --pipfile इसके बजाय पाइपफाइल को सिंक करने के लिए

और $ pipenv-setup check केवल जांच करने के लिए

उन सभी को हल करने के लिए एक आदेश

क्या पिपेनव-सेटअप पैकेज को पिपेनव में मर्ज करने की कोई योजना है?

@ पीटरडेमे

क्या पिपेनव-सेटअप पैकेज को पिपेनव में मर्ज करने की कोई योजना है?

@uranusjr @techalchemy ऊपर की चर्चा के आधार पर, मुझे लगता है कि पिपेनव का कुछ अलग दर्शन हो सकता है। लेकिन अगर अनुरक्षक सहमत हैं, तो मैं एक पुल अनुरोध सबमिट करना चाहता हूं और pipenv-setup को एकीकृत करने का प्रयास करना चाहता हूं

आप Pipfile.lock को बिल्टिन json मॉड्यूल के साथ हमेशा पार्स कर सकते हैं। अपने non-dev निर्भरता को अपने setup.py install_requires के लिए निकालें।
"default" कुंजी में version संख्याओं और markers के साथ पैकेज नाम के नेस्टेड "डिक्ट्स" शामिल हैं।
आपको किसी बाहरी आयात पर निर्भर रहने की आवश्यकता नहीं है।

@ किलो59 मैंने लोगों को ऐसा करते देखा है। उल्लेख करने के लिए एक टिप है, Pipfile.lock को data_file के रूप में setup.py में शामिल करना न भूलें (या इसे MANIFEST.in में शामिल करें)। और यह पिन की गई निर्भरताओं के साथ लॉकफाइल के लिए है। दूसरी ओर, pipfile, पार्स करने के लिए गैर-तुच्छ है, यदि आप Pipfile में सिमेंटिक वर्जनिंग चाहते हैं। एक ही निर्भरता आवश्यकता कई रूपों में दिखाई दे सकती है।

धन्यवाद @Madoshakalaka आपका टूल अच्छी तरह से काम करता है!

मैं अन्य साथियों से सहमत हूं कि Setup.py की निर्भरताएं पिपफाइल की परियोजना निर्भरताओं से अलग हैं। लेकिन फिर भी, मैन्युअल श्रम के बिना उन्हें सिंक करने के लिए प्रोग्राम करने योग्य तरीका एक महान समय बचाने वाली सुविधा है। साथ ही, टाइपो/सामान्य त्रुटियों से बचा जाता है।

काला किया गया setup.py भी एक अच्छा स्पर्श था: +1: