Pipenv: [प्रश्न] setup.py के साथ कैसे एकीकृत करें?

आपको इसे नीचे दिए गए कोड के साथ पूरा करने में सक्षम होना चाहिए। यह आपके वर्तमान प्रोजेक्ट से पिपफाइल को लोड करेगा और निर्भरताओं को एक पाइप संगत सूची में वापस कर देगा।

from pipenv.project import Project
from pipenv.utils import convert_deps_to_pip

pfile = Project(chdir=False).parsed_pipfile
requirements = convert_deps_to_pip(pfile['packages'], r=False)
test_requirements = convert_deps_to_pip(pfile['dev-packages'], r=False)

यदि आगे आपके कोई भी प्रश्न हों, तो हमें बताएं :)

उपरोक्त बहुत मददगार है। मैंने setup.py के साथ मुद्दों में भाग लिया है, जो कि वर्चुअलएन्व में setup.py install (या कुछ और) चलाने से पहले पिपेनव को स्थापित किया जा रहा है। इस समस्या का एकमात्र समाधान मैं सोच सकता हूं कि या तो एक परियोजना में पिपेनव को विक्रेता बनाना है, जो आदर्श से कम लगता है, या यहां तक ​​​​कि किसी भी तरह से from pipenv... आयात चलाने का प्रयास करने से पहले पिपेनव को स्थापित करने के लिए setup.py को हैक करना, जो लगता है गलत। किसी के पास कोई विचार या इससे बेहतर समाधान है?

क्या हमें Python समुदाय (PyPA, आदि) में दूसरों को भविष्य में Python रिलीज़ में आधिकारिक रूप से शामिल टूल के रूप में Pipenv को आशीर्वाद देने के लिए ~ परेशान करना चाहिए? मैं

क्या यह pipenv को setup_requires में जोड़ने में मदद करेगा? ऐसा लगता है कि इसे install_requires में जोड़ना भी आवश्यक हो सकता है जो दुर्भाग्यपूर्ण लगता है।

यह मत करो।

@kennethreitz "इस" से आपका क्या मतलब है? क्या आपका मतलब setup.py, @nateprewitt समाधान या पिछले दो सुझावों के साथ एकीकरण है?

तो उपयोगकर्ताओं को कैसे पता होना चाहिए कि उन्हें pipenv स्थापित करने की आवश्यकता है?

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

17 अक्टूबर, 2017 को सुबह 9:37 बजे, इद्दन अहहरोनसन नोटिफिकेशन @github.com ने लिखा:

तो उपयोगकर्ताओं को कैसे पता होना चाहिए कि उन्हें pipenv स्थापित करने की आवश्यकता है?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

तो मैं setup.py में @nateprewitt - के कोड का उपयोग कैसे कर सकता हूं?

@iddan : मैंने अपने प्रोजेक्ट कंकाल (https://github.com/elgertam/cookiecutter-pypackage/blob/master/%7B%7Bcookiecutter.project_slug%7D) में केवल पिपेनव के एक संस्करण को बेचने के द्वारा पिपेनव बूटस्ट्रैपिंग समस्या को हल करने का प्रयास किया है। %7D/setup.py)। अब तक मेरे पास कोई समस्या नहीं है, हालांकि मैं यह नहीं कह सकता कि मेरे पास ऐसी स्थिति में इसका परीक्षण करने के लिए बहुत सारे अवसर हैं जहां मैं setup.py का उपयोग करके एक पैकेज स्थापित करता हूं।

मैं समझ सकता हूं कि हम सेटअप.पी को लोड करते समय सीएलआई नहीं चलाने के बारे में चिंतित क्यों होंगे, लेकिन मैं जो बता सकता हूं, उससे मैं जिस कोड का उपयोग कर रहा हूं (यहां @nateprewitt की पोस्ट से कॉपी-पेस्ट किया गया) काफी सुरक्षित है।

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

@iddan , स्पष्ट होने के लिए, वह कोड पूरी तरह से एक पिपफाइल निर्भरताओं को एक आवश्यकताओं में परिवर्तित करने के लिए है। टीएक्सटी शैली प्रारूप जो पाइप पढ़ेगा। ऐसा लगता है कि केनेथ ने मूल पोस्ट से कुछ संशोधित किया है लेकिन मुझे यकीन नहीं है कि क्या।

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

मैं इसे बखूबी समझता हूं। जो मुझे समझ में नहीं आता है वह यह है कि आप क्या उम्मीद करते हैं कि जब कोई उपयोगकर्ता इस स्क्रिप्ट का उपयोग करके पैकेज डाउनलोड करता है और उसमें pipenv स्थापित नहीं होता है

@nateprewitt , अगर हम एक पैकेज वितरित करना चाहते हैं तो (सामान्य साधनों के माध्यम से, pip का उपयोग करके), क्या हमें निर्भरता सूची की एक प्रति setup.py या requirements.txt में बनाए रखना चाहिए ? मैं अपने पिपफाइल को सत्य के एकल स्रोत के रूप में उपयोग करने की उम्मीद कर रहा था।

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

जब तक मैं बुरी तरह से गलत नहीं हूँ, https://github.com/kennethreitz/pipenv/issues/209#issuecomment -278185133 में कोड उपयोग करने के लिए सुरक्षित है यदि आप एक पहिया (= बाइनरी डिस्ट) बना रहे हैं, लेकिन यदि नहीं आप sdist (= स्रोत जिला) बना रहे हैं।

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

sdist के साथ, setup.py वास्तव में इंस्टॉलेशन मशीन पर चलता है और इसलिए pipenv को वहां उपलब्ध होना चाहिए।

अरे हाँ। @tuukkamustonen , मेरा विशेष उपयोग मामला एक sdist है। चूंकि मैं $#$1 pip install #$ करने से पहले पैकेज उपयोगकर्ता को pipenv स्थापित करने की आवश्यकता नहीं चाहता, मुझे लगता है कि मैं setup.py के बाहर अपना install_requires प्राप्त करने के साथ फंस गया हूं setup.py (यानी मैन्युअल रूप से या किसी बिल्ड के हिस्से के रूप में)?

अगर मैं सही ढंग से पढ़ रहा हूं, तो मेरा मानना ​​​​है कि केनेथ और अन्य अनुरक्षक नहीं चाहते हैं कि हम Pipenv को एक परियोजना निर्भरता के रूप में मानें जैसा कि हम pytest , या यहां तक ​​​​कि एक सामान्य पैकेज निर्भरता के लिए कर सकते हैं। आदर्श रूप से, ऐसा लगता है कि हमें Pipenv को उसी तरह से इंस्टॉल और अपडेट करना चाहिए जैसे pip स्वयं, यानी pip जब पायथन स्थापित होता है या जब virtualenv बनाया गया है। केनेथ का यही मतलब था जब उसने कहा, "ऐसा मत करो।"

उस ने कहा, @isobit ने मेरे विचारों को प्रतिध्वनित किया कि Pipfile सत्य का एकमात्र स्रोत होना चाहिए। मैं पिपफाइल के पक्ष में दो सम्मोहक उपयोग के मामले देख सकता हूं (और अन्य भी हैं): पहला, एक सीआई/सीडी पाइपलाइन जो बिल्ड वातावरण को स्थापित करने के लिए पिपफाइल पर निर्भर करती है, आवश्यकताओं के आधार पर एक से कहीं अधिक मजबूत है। और दूसरा, एक योगदानकर्ता आँख बंद करके एक पिपफाइल-आधारित परियोजना स्थापित करने का प्रयास कर सकता है यदि python setup.py install उसकी अपेक्षा के अनुरूप काम नहीं करता है तो वह निराश हो सकता है। यह देखते हुए कि न तो पिपेनव या पिपफाइल-जागरूक पाइप अभी तक मानक पायथन उपकरण हैं, और पिपेनव वास्तव में पिपफाइल के लिए संदर्भ कार्यान्वयन है, हमारे पास समस्या को हल करने के लिए कुछ विकल्प हैं:

1) अपने प्रोजेक्ट प्रलेखन में निर्दिष्ट करें कि आपका प्रोजेक्ट Pipenv पर निर्भर करता है। आप अभी भी अपने Pipenv पर अपने setup.py पर निर्भर हो सकते हैं, और यह टूट जाएगा यदि Pipenv आपके पायथन वातावरण में स्थापित नहीं है। सीधे तौर पर, आपके कोड में योगदानकर्ता को Pipenv को मैन्युअल रूप से virtualenv में इंस्टॉल करना होगा ताकि प्रोजेक्ट को setup.py के साथ इंस्टॉल किया जा सके।
2) अभी भी setup.py requirements.txt पर निर्भर है, जिसे आप अपने Pipfile के आधार पर समय-समय पर जेनरेट करते हैं। यह pip और setuptools के साथ पूरी तरह से संगत रहता है, लेकिन जब भी प्रोजेक्ट बनाया और तैनात किया जाता है तो requirements.txt उत्पन्न करने के लिए किसी भी रखरखाव की आवश्यकता होती है। इसका एक संभावित बदलाव CI/CD पाइपलाइन के निर्माण के समय requirements.txt को अपडेट करने के लिए होगा।
3) पिपेनव के एक संस्करण को एक प्रोजेक्ट में वेंडराइज़ करें और इसे from _vendor.pipenv.project import Project... के अंदर setup.py का उपयोग करके कॉल करें। इसका एक रूपांतर केवल विक्रेताकृत संस्करण से आयात करना हो सकता है जब वैश्विक आयात विफल हो जाता है।
4) कुछ अन्य विकल्प जो यहां प्रस्तुत नहीं किए गए हैं और जिनके बारे में मैं सोचने के लिए पर्याप्त स्मार्ट नहीं हूं।

मैं व्यक्तिगत रूप से (3) का उपयोग कर रहा हूं (देखें https://github.com/kennethreitz/pipenv/issues/209#issuecomment-300550425) जब तक कि पिपफाइल एक सामान्य मानक से अधिक नहीं हो जाता है, उस बिंदु पर मेरे पास मेरी कोई भी परियोजना नहीं होगी सीधे पिपेनव कोड पर निर्भर करते हैं, क्योंकि पिपेनव स्पष्ट रूप से एक पिपफाइल पर आधारित वर्चुअलएन्व के प्रबंधन के लिए एक उपकरण के रूप में प्रतीत होता है, और जरूरी नहीं कि एक पिपफाइल पुस्तकालय ही हो।

मुझे आशा है कि यह मेरे द्वारा यहां पढ़ी गई बातों के आधार पर इस मुद्दे को स्पष्ट करता है, लेकिन अगर मैंने कुछ गलत कहा या कुछ गंभीर कहा, तो कृपया मुझे @nateprewitt बताएं।

मुझे लगता है कि यहां मुद्दा requirements.txt के मूल दुरुपयोग (आईएमओ) से शुरू हुआ है। यह pipenv के उपयोग से अलग है।

मैं डोनाल्ड स्टफ्ट के इस अद्भुत लेख की ओर इशारा करने जा रहा हूं, setup.py बनाम आवश्यकताएँ.txt:
https://caremad.io/posts/2013/07/setup-vs-requirement/

टीएल; डीआर (लेकिन आपको वास्तव में पढ़ना चाहिए): setup.py का install_requires एक पैकेज की आवश्यकताओं (निर्भरता) का विस्तार करने के लिए है। requirements.txt (जिसे यहां Pipfile / Pipfile.lock कॉम्बो द्वारा प्रतिस्थापित किया जाएगा) का उपयोग यह सूचीबद्ध करने के लिए किया जाना चाहिए कि कौन से सटीक पैकेजों का उपयोग आवश्यक चीज़ों को पूरा करने के लिए किया जाएगा, इसके आधार पर प्रतिलिपि प्रस्तुत करने योग्य वातावरण बनाने के लिए setup.py से मेटाडेटा।
install_requires को requirements.txt से पॉप्युलेट करना पीछे की ओर जाने जैसा है।

setup.py का install_requires =/= requirements.txt (या Pipfile / Pipfile.lock )।
Pipfile (या बल्कि Pipfile.lock ) ऐप के वातावरण में इंस्टॉल किए जाने वाले पैकेजों की सच्चाई का एकमात्र स्रोत होना चाहिए।
setup.py का install_requires एक वैध Pipfile.lock उत्पन्न करने के लिए प्रयुक्त मेटाडेटा प्रदान करता है।

मुझे लगता है कि यहीं से घर्षण आ रहा है। मुझे आशा है कि यह समझ में आता है।

मुझे वह उत्तर बहुत पसंद है, विन्सेंट, और मैं Pipfile.lock के लिए पूर्ण (और बेहतर) प्रतिस्थापन होने पर पूरी तरह सहमत हूं requirements.txt ।

कुछ महीनों के लिए पिपेनव का उपयोग करने के बाद, हालांकि, मेरे Pipfile के उपयोग से मुझे लगता है कि install_requires वास्तव में Pipfile में लगभग समान है। अगर मुझे numpy की आवश्यकता है, तो मैं pipenv install numpy और मेरे पिपफाइल के [packages] समूह में एक नई प्रविष्टि जाती है: numpy = "*" । दूसरे शब्दों में, मेरा उपयोग requirements.txt से बिल्कुल अलग है, जिसे मैं pip freeze > requirements.txt का उपयोग करने से पहले उत्पन्न करता था।

शायद यह सिर्फ एक अजीब तरीका है कि मैं पिपेनव का उपयोग कर रहा हूं, और मैं अनाज के खिलाफ जा रहा हूं (मैं प्रोजेक्ट निर्देशिका के अंदर .venv/ में अपना वर्चुअलएन्व भी स्थापित करता हूं, इसलिए मैं एक दुष्ट पाइथोनिस्टा हूं), जिसमें अगर मैं setup.py और Pipfile के बीच अलगाव की दीवार रखने के पायथन समुदाय के सम्मेलन का आसानी से पालन कर सकता हूं | Pipfile.lock | requirements.txt ।

मैं यहाँ क्या खो रहा हूँ, @vphilippon?

जानकारी के लिए धन्यवाद, @vphilippon। शायद हम इसके बारे में पीछे की ओर जा रहे हैं, ऐसा लगता है कि हम वास्तव में जो चाहते हैं वह उल्टा है- एक तरह से हमारे पिपफाइल में install_requires से एब्सट्रैक्ट डिप्स का उपयोग करें, जैसे डोनाल्ड ने -e . में requirements.txt -e . के संबंध में उल्लेख किया है। requirements.txt । ऐसा लगता है कि इसके बारे में पहले से ही कोई समस्या थी (#339), लेकिन यह कहीं नहीं गया।

क्या यह पहले से ही पिपफाइल सिंटैक्स द्वारा कवर किया गया है? मैंने अभी देखा है कि अनुरोध पुस्तकालय पिपफाइल अपने पैकेज अनुभाग में "e1839a8" = {path = ".", editable = true, extras=["socks"]} का उपयोग करता है। पिपफाइल उदाहरणों में कुछ ऐसा ही स्पष्ट है, लेकिन मुझे कोई अन्य दस्तावेज नहीं दिख रहा है।

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

अब, इस पर चलते हैं।

मैं इस कथन से शुरू करूँगा @elgertam :

[...] Pipfile का मेरा उपयोग मुझे लगता है कि install_requires वास्तव में लगभग समान है जो पिपफाइल में जाता है। अगर मुझे numpy की जरूरत है, मैं pipenv numpy स्थापित करता हूं और मेरे पिपफाइल के [पैकेज] समूह में एक नई प्रविष्टि जाती है [...]

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

दूसरे शब्दों में, मेरा उपयोग आवश्यकताओं से पूरी तरह से अलग है।

हैरानी की बात है कि यदि आप इसके बारे में सोचते हैं तो आपका उपयोग इतना अलग नहीं है:

• आपका पिछला वर्फ़्लो: pip install stuff -> pip freeze > requirements.txt -> requirements.txt से requirements.txt install_requires फ़ीड करें
• आपका नया (प्रयास किया गया) कार्यप्रवाह: pipenv install stuff -> Pipfile स्वचालित रूप से अपडेट किया गया -> $#$ Pipfile $#$ के साथ install_requires को खिलाने का प्रयास कर रहा है।
• इरादा क्या है: install_requires में सामान जोड़ें -> pipenv install -> पर्यावरण और Pipfile.lock अपडेट किए गए हैं।

और उस इच्छित तरीके से काम करने के लिए, आप एक Pipfile चाहते हैं जो बताता है कि आप अपना ऐप इंस्टॉल करना चाहते हैं।
requests Pipfile जैसा कुछ @isobit द्वारा लिंक किया गया है।

या, एक उदाहरण:

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

[dev-packages]
pytest = ">=2.8.0"
tox = "*"

[packages]
"-e ." = "*"

आपका Pipfile आपके पर्यावरण का वर्णन करने के लिए है, न कि किसी पैकेज की निर्भरता का। जैसा कि आप देखते हैं, ऊपर Pipfile परिभाषित करता है कि मैं क्या स्थापित करना चाहता हूं, जो संपादन योग्य मोड में स्थानीय पैकेज है।

यह थोड़ा "बेकार" लग सकता है, क्योंकि अभी यह सब एक ही पैकेज द्वारा संचालित है, लेकिन मान लीजिए कि आप अपना ऐप इंस्टॉल करना चाहते हैं, लेकिन requests[security] के साथ, लेकिन यह आपके ऐप से सख्त निर्भरता नहीं है, आप pipenv install requests[security] करें, और फिर:

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

[dev-packages]
pytest = ">=2.8.0"
tox = "*"

[packages]
"-e ." = "*"
requests = { extras = ['security'] }

और वॉयला, यहां आपकी अमूर्त आवश्यकताओं और आपकी ठोस आवश्यकताओं के बीच अंतर का एक उदाहरण है। यदि आप gunicorn या वातावरण में आवश्यक कुछ भी स्थापित करना चाहते हैं, तो वही होता है, लेकिन यह ऐप का हिस्सा नहीं है।

मैं यहाँ क्या खो रहा हूँ, @vphilippon? Pipfile का [पैकेज] भी install_requires या test_require में उपयोग करने के लिए विवश क्यों है?

अगर मैंने इसे अच्छी तरह से समझाया है, तो आप देख सकते हैं कि यह बस दूसरी तरफ होना चाहिए।
आप अपनी निर्भरताओं को install_requires में डालते हैं, आप Pipfile में पैकेज डालते हैं, और फिर आपको पुनरुत्पादन के लिए Pipfile.lock के साथ पर्यावरण मिलता है (क्योंकि यह आपके समाधान और सम्मान करेगा) पैकेज निर्भरता)।

test_require के लिए, मैं मानता हूँ कि मुझे यकीन नहीं है कि यह इस सब में फिट बैठता है। IIRC, इसकी एक setuptools विशिष्ट विशेषता है। हम तर्क दे सकते हैं कि यह परीक्षण के लिए अमूर्त निर्भरताओं का एक सेट है, और उम्मीद है कि pipenv सभी पैकेजों के लिए pipenv install --dev #$ को हल करने और स्थापित करने के लिए, लेकिन मुझे लगता है कि यह बिल्कुल सही नहीं है। मेरे पास इस पर और इसके आसपास के तर्क के बारे में कोई स्पष्ट विचार या राय नहीं है, क्षमा करें।

मुझे आशा है कि यह सब किसी तरह समझ में आता है।

@vphilippon आपने इसे काफी अच्छी तरह समझाया, और मुझे लगता है कि आपने मुझे विश्वास दिलाया है।

TL; DR: setup.py में अमूर्त, बिल्कुल आवश्यक निर्भरता निर्दिष्ट करें, फिर Pipfile और Pipfile.lock में संदर्भ (और इस प्रकार संक्षिप्तता) जोड़ें, जिसमें शानदार "-e ." = "*" भी शामिल है।

https://github.com/kennethreitz/pipenv/issues/209#issuecomment -337409290 के साथ एक समस्या यह है कि जब हम अपने ऐप को सर्वर पर तैनात करना चाहते हैं, तो हमें एक प्रतिलिपि प्रस्तुत करने योग्य वातावरण नहीं मिल रहा है।

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

(सकर्मक निर्भरताओं के सटीक संस्करणों को मैन्युअल रूप से घोषित करना एक विकल्प नहीं है - रास्ता बहुत बोझिल है।)

इस उपयोग के मामले में, हमें requirements.txt स्टाइल लॉकफाइल पर निर्भर होना चाहिए (जो सकर्मक निर्भरताओं के लिए भी सटीक संस्करण निर्दिष्ट करता है)। हालांकि, ऐसा नहीं लगता है कि pipenv pipenv lock -r (जैसे pipenv lock --no-dev -r ) में विकास आवश्यकताओं को बाहर करने की अनुमति देता है, ताकि हम वास्तव में ऐसे requirements.txt (जो तब हो सकते हैं) को तैयार कर सकें install_requires में पढ़ें)?

मैं डोनाल्ड स्टफ के लेख को उद्धृत करूंगा:

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

दूसरे शब्दों में: ऐप पैकेज नहीं है। ऐप पर्यावरण है, जिसमें ठोस निर्भरताओं का एक सेट स्थापित है। एक ऐप निर्भरता को requirements.txt (या Pipfile / Pipfile.lock ) द्वारा दर्शाया जाना चाहिए, न कि एक पैकेज install_requires द्वारा।

व्यक्तिगत रूप से, मैं यह कहना चाहूंगा कि पिन की गई निर्भरता का पूरा सेट (सकर्मक एक सहित) ऐप के लिए requirements.txt में होना चाहिए, पैकेज के setup.py में नहीं। यह इस विचार को रेखांकित करता है कि किसी ऐप को तैनात करना pip install myapp==1.0.0 के साथ नहीं किया जाता है, बल्कि pip install -r requirements.txt (या pipenv install के साथ Pipfile.lock ) के साथ किया जाता है, जहां requirements.txt में myapp==1.0.0 के साथ-साथ अन्य सभी निर्भरताएँ और सकर्मक निर्भरताएँ शामिल हैं, जिन्हें पिन किया गया है।
ऐसा लगता है कि मैं थोड़ी दूर जा रहा हूं, लेकिन मैंने ऐसे संदर्भ में काम किया है जहां तैनात "ऐप" पैकेजों के एक सेट द्वारा संचालित होता है। ऐप का प्रतिनिधित्व करने वाला एक भी पैकेज नहीं है, इसलिए यह धारणा कि "पैकेज ऐप नहीं है" मेरे चेहरे पर 😄 पर बहुत पहले फेंक दिया गया था।

मुझे एक मजबूत भावना है कि Pipenv/Pipfile/Pipfile.lock इस विचार का अनुसरण करता है।
यही कारण है कि Pipfile.lock से setup.py के install_requires तक जाने के लिए एक अंतर प्रतीत होता है: इसका वास्तव में किसी भी मामले में ऐसा करने का मतलब नहीं है।

@maintainers मैं यह जानने के लिए यहां आपका इनपुट चाहता हूं कि क्या यह वास्तव में आप यह सब कैसे देखते हैं। मैं एक दृष्टिकोण का प्रचार कर रहा हूं कि हमें निर्भरता के साथ कैसा व्यवहार करना चाहिए, लेकिन मैं आपकी जगह पर बात नहीं करना चाहता।

@vphilippon मुझे लगता है कि अलग-अलग दृष्टिकोण और शब्दावली हैं। लेकिन अंततः, हम स्थापित करने के लिए पिन की गई निर्भरताओं की एक सूची चाहते हैं। तो एक requirements.txt पिन किए गए संस्करणों के साथ (या ऐसी घोषित निर्भरताओं वाला पैकेज, वास्तव में कोई फर्क नहीं पड़ता)। सवाल यह है कि वास्तव में ऐसी फाइल कैसे तैयार की जाए?

pip-compile ( पाइप-टूल्स के ) के साथ, मैं ऐसे requirements.txt को requirements.in $ से संकलित कर सकता हूं और इसमें केवल गैर-देव निर्भरताएं होंगी जिनकी मेरे ऐप को आवश्यकता है। मुझे यकीन नहीं है कि मैं आपकी प्रतिक्रिया की सही व्याख्या कर रहा हूं - क्या आपका वास्तव में मतलब है कि हमें हाथ से एक पिन की गई निर्भरता requirements.txt बनाए रखनी चाहिए (जो पहले से ही setup.py में है, उसे थोड़ा-थोड़ा दोहराते हुए), इसके लिए भी सकर्मक निर्भरता? यह समाधान नहीं हो सकता...

अगर वहाँ pipenv lock --no-dev -r होता, तो मुझे लगता है कि इससे इस समस्या का समाधान हो जाएगा।

@tuukkamustonen भ्रम के लिए क्षमा करें, मैं वास्तव में केवल install_requires बनाम requirements.txt / Pipfile / Pipfile.lock के विचार को संबोधित कर रहा था।

तो एक आवश्यकताएँ। पिन किए गए संस्करणों के साथ txt (या ऐसी घोषित निर्भरताओं वाला पैकेज, वास्तव में कोई फर्क नहीं पड़ता)।

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

हालांकि, ऐसा नहीं लगता है कि pipenv pipenv lock -r . में विकास आवश्यकताओं को बाहर करने की अनुमति देता है

लेकिन अंततः, हम स्थापित करने के लिए पिन की गई निर्भरताओं की एक सूची चाहते हैं। [...] सवाल यह है कि वास्तव में ऐसी फाइल को कैसे तैयार किया जाए? [...] पिप-कंपाइल (पाइप-टूल्स के) के साथ, मैं ऐसी आवश्यकताओं को कंपाइल कर सकता हूं।

आह, मैंने पहले उस हिस्से को छोड़ दिया, क्षमा करें। और ऐसा लगता है कि आप सही हैं: मुझे pipenv install --not-dev-stuff कहने का कोई तरीका नहीं मिल रहा है (मुझे पूरा यकीन था कि एक अजीब था), और एक गैर-देव वातावरण उत्पन्न करता है। फिर 2 अलग सेक्शन होने का क्या मतलब है? मुझे अब कुछ याद आ रहा है, और यह setup.py के उपयोग से संबंधित नहीं है। शायद यह एक नए मुद्दे पर चर्चा करने लायक है।

संपादित करें:
मैंने यहां गलती की। मुझे वास्तव में देव पैकेज के बिना Pipfile.lock उत्पन्न करने का कोई तरीका नहीं मिला, लेकिन , एक नए वातावरण में, मौजूदा Pipfile / Pipfile.lock के साथ, pipenv install कर रहा था देव पैकेज स्थापित नहीं करता है। यह @tuukkamustonen के बिंदु को हल नहीं करता है, लेकिन मैं गलत था जब यह बताते हुए कि "ठेस वातावरण" स्थापित करने का कोई तरीका नहीं था, मेरी गलती।

ओह, यह पकड़ने के लिए बहुत कुछ था।

जब तक कि मैं बुरी तरह से गलत नहीं हूं, #209 (टिप्पणी) में कोड का उपयोग सुरक्षित है यदि आप एक पहिया (= बाइनरी डिस्ट) बना रहे हैं, लेकिन यदि आप sdist (=source dist) का निर्माण नहीं कर रहे हैं।

@tuukkamustonen यह केवल तैनाती के लिए एक स्टैंडअलोन स्क्रिप्ट में उपयोग करने के लिए है, इसे अपने setup.py में शामिल न करें। कई महीने पहले हमारे पास pipenv lock -r होने से पहले यह एक अर्ध-हैकी वर्कअराउंड है। हालांकि यह दृष्टिकोण packages और dev-packages को विभाजित करने के आपके उपयोग के मामले के लिए काम करेगा।

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

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

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

मुझे लगता है कि आप परियोजना की लंबाई के लिए हमारी दृष्टि के अनुरूप बहुत अच्छी तरह से हैं। यह सब इतनी अच्छी तरह से व्यक्त करने के लिए धन्यवाद @vphilippon!

ऐसा लगता है कि इस चर्चा के अन्य प्रासंगिक भागों को #942 में स्थानांतरित कर दिया गया है, इसलिए मुझे लगता है कि हम यहां अच्छे हैं। अगर मैंने कुछ भी संबोधित नहीं किया तो कृपया मुझे पिंग करें।

मैंने https://github.com/pypa/pipfile/issues/98 में एक ठोस प्रस्ताव के साथ पालन किया जो मुझे विश्वास है कि हमें कुछ कार्रवाई योग्य और व्यावहारिक देता है जो पायथन पुस्तकालयों को बनाए रखने के लिए डीएक्स में सुधार कर सकता है।

विचार?

import json, jmespath

install_requires = []
with open('Pipfile.lock') as f:
    context = json.loads(f.read())
    install_requires.extend(map(
        lambda n, v : n + v,
        jmespath.search('default | keys(@)', context),
        jmespath.search('default.*.version', context),
    ))

setup(
    name='foobar',
    packages=find_packages(),
    setup_requires=['jmespath'],
    install_requires=install_requires,
)

@cornfeedhobo मेरी समझ यह है कि setup_requires पाइप के साथ अच्छा नहीं खेलता है। क्या आप इस बारे में थोड़ा विस्तार से बता सकते हैं कि आप इस नमूने का उपयोग करने का सुझाव कैसे देंगे?

नमूना तब तक काम नहीं करेगा जब तक आप पहले jmespath स्थापित नहीं करते क्योंकि setup.py का मूल्यांकन सामान्य पायथन कोड के रूप में किया जाता है। setup_requires तर्क वास्तव में कुछ भी हासिल नहीं करता है: यदि प्रोग्राम इतना दूर हो जाता है, तो jmespath स्थापित होने की गारंटी है।

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

@epot मुझे इसकी जानकारी नहीं थी

@uranusjr विवरण के साथ सुविचारित उत्तर के लिए धन्यवाद। मैं अभी इस पूरे मामले की छानबीन कर रहा हूं, इसलिए मैं और अधिक शर्मिंदगी के लिए वापस आ सकता हूं। मैं pypa/pipfile#98 . पर भी नज़र रख रहा हूँ

क्या होगा अगर हमें jmespath की आवश्यकता नहीं है?

import json


install_requires = []
tests_require = []

with open('Pipfile.lock') as fd:
    lock_data = json.load(fd)
    install_requires = [
        package_name + package_data['version']
        for package_name, package_data in lock_data['default'].items()
    ]
    tests_require = [
        package_name + package_data['version']
        for package_name, package_data in lock_data['develop'].items()
    ]

@mschwager आप संस्करण को पिन नहीं करना चाहते हैं, या उपयोगकर्ताओं को मुश्किल समय होगा। #1921 == का उपयोग कर एक पुस्तकालय का एक उदाहरण है जो उपयोगकर्ता के निर्माण को तोड़ देता है।

मेरी क्षमा याचना, लेकिन पैकेज के रूप में उपयोग करने के लिए setup.py का उपयोग करने या उक्त पैकेज की निर्भरता को प्रबंधित करने के लिए requirements.txt / Pipfile के बीच क्या अंतर है? आवश्यक libs setup.py और requirements.txt / Pipfile के बीच समान होना चाहिए, है ना? इसलिए Pipfile को एकीकृत न करने का कोई कारण नहीं है। setup.py पहले ही requirements.txt पार्स कर चुका है। यह Pipfile को पार्स करने में सक्षम क्यों नहीं होना चाहिए?

requirements.txt से छुटकारा पाने के लिए बहुत अच्छा होगा और केवल Pipfile . का उपयोग करें

नहीं, उनके समान होने का कोई कारण नहीं है। यह काफी आमूलचूल धारणा है, और समुदाय में कई लोग इससे भिन्न भीख माँगेंगे।

हालांकि, वास्तव में ऐसे कारण हैं कि वे _can_ समान हो सकते हैं। पिपेनव इसे बाहर नहीं करता है। यह अभी दायरे से बाहर है, और इस परियोजना द्वारा समर्थित नहीं है। आप इसका समर्थन करने के लिए पूरी तरह से एक पुस्तकालय का निर्माण कर सकते हैं, और पीईपी 518 का लाभ उठा सकते हैं, जो कि बिल्ड-टाइम समर्थन प्रदान करने के लिए पीपी 10.0 में निहित है।

जैसा कि आपने कहा था, पिपफाइल को पार्स करने के लिए setup.py को अनुमति नहीं देने का कोई कारण नहीं है। मैं आपके ऐसा करने के लिए तत्पर हूं :)

समझें कि कुछ लोगों को setup.py के अमूर्त काम पसंद हैं, फिर भी यह जरूरी नहीं है? मेरा मतलब है कि गोलांग केवल ठोस आवश्यकताओं से ग्रस्त है, लेकिन फिर भी अपने स्वयं के कांटे के साथ एक आवश्यक lib को प्रतिस्थापित करने में सक्षम है क्योंकि यह नाम से मेल खाता है? समझा जा सकता है कि setup.py इंटरगेशन अभी दायरे में नहीं है।

हालांकि, यह देखना दिलचस्प होगा कि पिपेनव का दीर्घकालिक रोडमैप क्या है। यह देखना अच्छा होगा कि यह पायथन में टूल पर जाता है। उदाहरण के लिए किसी भी तरह से setup.py को प्रतिस्थापित करता है या उपयोगकर्ता के लिए उपयुक्त setup.py उत्पन्न करता है, किसी भी तरह से पिपेनव वास्तव में पैकेज मैनेजर होने का कमाल है। बस सोच रहा था कि क्या setup.py को शामिल करने का दायरा बढ़ाने की संभावना है?

यदि pipenv npm आदि की तरह है, तो उनका package.json दूरस्थ स्थापना की अनुमति देता है, कोई कारण नहीं है कि pipenv setup.py को इंटरैक्ट या प्रतिस्थापित नहीं कर सकता है, जिससे इसे दायरे में लाया जा सकता है। क्या मुझे समझ में आ रहा है या ऐसा लगता है कि मैं पागल गोलियां ले रहा हूं?

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