हम्म, शायद हमें PyPI में उपलब्ध सभी पैकेज संस्करणों को सूचीबद्ध करने के लिए एक कमांड की आवश्यकता है।
आपको क्या लगता है?

पसंद:

$ pip list Django

1.2.4

1.2.3

1.2.2

1.2.1

1.2

1.1.3

1.1.2

1.0.4

$

Original Comment By: Hugo Lopes Tavares

मुझे वह विचार पसंद है।

Original Comment By: CarlFK

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

इसे यहां देखें: https://bitbucket.org/hltbra/pip-list-
कमांड/चेंजसेट/e5c135a46204

Original Comment By: Hugo Lopes Tavares

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

Original Comment By: Carl Meyer

जब तक मेरा अन्य ईआर लागू किया जाता है, तब तक मैं इसे खोज में जोड़ने के साथ ठीक रहूंगा
इतना भी कि जब मैं django के संस्करणों की तलाश करता हूं तो मुझे 3000 लाइनें (वास्तव में) नहीं मिलती हैं।
(सभी django-foo . के कारण "पाइप सर्च django" के लिए 1000 से अधिक हिट हैं
पैकेज। )

Original Comment By: CarlFK

मुझे लगता है कि यह दिखाना अनावश्यक है कि कौन सा संस्करण तब तक स्थापित किया जाएगा जब तक
उपलब्ध संस्करणों की एक सूची है, क्योंकि यह निर्धारित करना आसान है कि कौन सा
ये नवीनतम है। इसके अलावा एक नए ध्वज का उपयोग करने का कोई कारण नहीं है
इस सूची के आउटपुट को सक्षम करें, क्योंकि ओवरहेड शून्य की ओर जाता है। यह है
बस एक छोटा सा बदलाव:
https://bitbucket.org/jumpa/pip/changeset/62076643cf33

Original Comment By: jumpa

हाय कार्ल, हालांकि मेरे पास सर्च कमांड में एक विकल्प जोड़ने के बारे में है, लेकिन मेरा डर है
ऐसा हुआ जो कमांड को स्थापित करने के लिए हुआ: यदि आप "अपग्रेड" करना चाहते हैं a
पैकेज, आपको "इंस्टॉल" विकल्प का उपयोग करने की आवश्यकता है - यह अजीब है, और हम इसे जानते हैं।

और यदि अधिकांश लोगों को लगता है कि खोज में विकल्प जोड़ना बेहतर है, तो मुझे भी नहीं लगता
खोज --संस्करणों या खोज -v का उपयोग करने में बहुत समस्या है।

Original Comment By: Hugo Lopes Tavares

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

और मैं कार्लएफके से सहमत हूं कि हमें खोज में सुधार करने की भी आवश्यकता है
संकीर्ण करने में आसान। समस्या यह है कि हम इस बात पर निर्भर करते हैं कि PyPI का API हमें क्या देता है,
जो ज्यादा नहीं है: हम सभी पीईपीआई डाउनलोड नहीं करने जा रहे हैं और रेगेक्स नहीं कर रहे हैं
स्थानीय रूप से खोजें! मैं खोज करने के लिए --exact ध्वज की तरह कुछ के पक्ष में हूं
इस परिवर्तन का हिस्सा है, इसलिए आप खोज सकते हैं उदाहरण के लिए "--exact django" और केवल प्राप्त करें
अपने परिणाम में ही django।

Original Comment By: Carl Meyer

हाय जम्पा, xmlrpc से प्राप्त संस्करणों का उपयोग करके संस्करण दिखाने का बढ़िया विचार
कनेक्शन!

मुझे पिप की तलाश में निम्नलिखित स्निप मिला है:

pip                       - pip installs packages.  Python packages.  An

Easy_install प्रतिस्थापन (संस्करण: 0.2, 0.2.1, 0.3, 0.3.1, 0.4, 0.5, 0.5.1,
0.6, 0.6.1, 0.6.2, 0.6.3, 0.7, 0.7.1, 0.7.2, 0.8, 0.8.1, 0.8.2)

यह बहुत सारे संस्करणों का उपयोग करते हुए पैकेजों की इतनी बड़ी सूची होने जा रही है -
क्योंकि हमारी खोज नामों और सारांशों की परवाह करती है। क्या हमें इसकी परवाह करनी चाहिए?

Original Comment By: Hugo Lopes Tavares

एक एंड्यूसर के रूप में, मुझे एक अलग सूची कमांड* रखने का विचार पसंद है। समय के रूप में
एक अलग कमांड पर चला जाता है जिसे अलगाव में संशोधित करना और बढ़ाना आसान हो सकता है। प्रति
एक अलग सूची कमांड को और अधिक उपयोगी बनाएं जिससे आप संकेत कर सकें कि कौन सा संस्करण, if
कोई भी, वर्तमान में स्थापित है।

pip list Django


1.2.4

1.2.3 installed

1.2.2

1.2.1

1.2

1.1.3

1.1.2

1.0.4

नोट: कई लोकप्रिय पैकेज मैनेजर जैसे YUM(RedHat), pkglist(BSD),
dpkg(Debain) एक अलग सूची ध्वज या आदेश प्रदान करता है।

Original Comment By: Kelsey Hightower

कार्ल, मैं इस मुद्दे के बारे में एक और दिन सोच रहा था, और मुझे इससे सहमत होना होगा
केल्सी: एक और आदेश बुरा नहीं है।

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

यह थोड़ा अजीब है।

आइए वर्णन करने का प्रयास करें:

$ pip search -v --exact Django

बनाम

$ pip list Django

केल्सी का यह दिखाने का विचार कि कौन सा संस्करण स्थापित है, सूची में सुधार करता है
आदेश।

Original Comment By: Hugo Lopes Tavares

मैंने सर्च कमांड में बदलाव किए हैं।

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

यहाँ मेरा परिवर्तन सेट है: https://github.com/phuihock/pip/commit/46bad23b5bf31850a02803ea1ca18be5deca9db3

इसके साथ क्या स्थिति है? क्या कोई पाइप का उपयोग करके PyPI पर नवीनतम उपलब्ध संस्करण देख सकता है?

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

बस यहां यह जोड़ना चाहता था कि संस्करण दिखाने के तरीके के लिए खोज करते समय मैं बस इस धागे में भाग गया ... मैंने pip search -v पैकेज की कोशिश की - किसी भी तरह से मुझे सहज ज्ञान होता: पैकेज का एक वर्बोज़ विवरण संस्करण जानकारी सहित स्थापित किया जाए ...

मेरे एक सहयोगी द्वारा मुझसे इसके बारे में पूछे जाने के बाद भी मुझे _just_ एहसास हुआ कि यह कार्यक्षमता अभी भी लागू नहीं हुई है। क्या कोई योजना है कि यह पीआईपी के आने वाले संस्करणों में उपलब्ध होगी?

मेरा मानना ​​है कि यह पीआर प्रासंगिक हो सकता है, जिस पर वर्तमान में काम किया जा रहा है?

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

+1,000,000

और अब कैसा है?

अब, क्या यह दिखाने का कोई तरीका है कि कौन सा संस्करण इसे स्थापित किए बिना नवीनतम है?
यह मुद्दा 2011 से खुला है और मैंने ऊपर जो पैच देखा है वह सिर्फ एक लाइन है। :(

यह सक्षम करने के लिए एक छोटी सी सुविधा की तरह लगता है, इस बिंदु पर apt-cache madison कहने के बराबर कोई विकल्प कैसे नहीं है?

खोज करते समय मैं वास्तव में PyPi पैकेज का नवीनतम संस्करण देखना चाहूंगा। एक सटीक मिलान होने से काम होता है, लेकिन मैं awk को वर्कअराउंड के रूप में उपयोग करता हूं।

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

wget -qO- https://pypi.python.org/pypi/uWSGI | egrep -o "uwsgi-[0-9].[0-9].[0-9][0-9].tar.gz" | सॉर्ट -यू

wget -qO- https://pypi.python.org/pypi/uWSGI/json | grep '"version"'

@andreif यह हमेशा सही संस्करण नहीं ढूंढेगा (पाइप अल्फा, बीटा, रिलीज उम्मीदवारों इत्यादि को अनदेखा करता है, जब तक कि --pre प्रदान नहीं किया जाता है)। यह करीब है (लेकिन कोई गारंटी नहीं है):
wget -qO- https://pypi.python.org/pypi/uWSGI/json | grep -E ' {8}"[0-9."]*": \[' | sort -V | tail -n 1 | tr -d ' ":['

ठीक है, तो JSON प्रतिक्रिया में कुछ इस तरह शामिल होना चाहिए "pre-version": "1.2.3a4" , ताकि कोई सरल अभिव्यक्ति के साथ दोनों को grep कर सके।

मैं वास्तव में इस मुद्दे को समझ नहीं पा रहा हूं... यह किस बारे में है?

• pip install पर एक नया विकल्प जोड़ना जो केवल पैकेजों के समाधान तक पाइप चलाएगा और चयनित पैकेजों को प्रिंट करेगा और बाहर निकलेगा (इंस्टॉलेशन को छोड़कर)?
• pip search का उपयोग करते समय पैकेज नामों के आगे नवीनतम संस्करण दिखा रहा है?
  
  
  
  • PyPI पर पैकेज का नवीनतम संस्करण देखने में सक्षम होने के नाते?
  
  

ऐसा लगता है कि उत्तरार्द्ध मुझे हल कर दिया गया है और पूर्व को शायद एक नया समर्पित मुद्दा मिलना चाहिए।

@pradyunsg ठीक है, अगर मुझे सही याद है, तो मुझे यह जांचने का एक आसान तरीका चाहिए कि वर्तमान में कौन सा संस्करण उपलब्ध है (रिलीज और प्री-रिलीज दोनों)। यह संस्करण pip install -U [--pre] द्वारा स्थापित किया जाएगा।

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

pkg="foo"; pip install --download /dev/null --no-cache-dir --no-binary :all: "$pkg" 2>&1 | egrep -i "$pkg"'-' | head -1 | egrep -io "$pkg"'-[^ ]+' | sed 's/^'"$pkg"'-\(.*\)\.tar\.gz$/\1/g'

पोस्ट --download - पदावनति संस्करण...

pkg="foo"; tmp="$(mktemp -d)"; pip download -d "$tmp" --no-cache-dir --no-binary :all: "$pkg" 2>&1 | egrep -i "$pkg"'-' | head -1 | egrep -io "$pkg"'-[^ ]+' | tr A-Z a-z | sed 's/^'"$pkg"'-\(.*\)\.tar\.gz$/\1/g'

कुछ इस तरह का उपयोग करना:

pip install foo==

सभी उपलब्ध संस्करणों की एक सूची देता है (एक वैध pypi उपलब्ध पैकेज के लिए, इस मामले में अणु):

Could not find a version that satisfies the requirement molecule== (from versions: 1.20.1, 1.20.3, 1.21.1, 1.22.0, 1.23.0, 1.25.0, 1.25.1, 2.10.0, 2.10.1, 2.11.0, 2.12.0, 2.12.1, 2.13.0, 2.13.1, 2.14.0, 2.15.0, 2.16.0, 2.17.0, 2.18.0, 2.18.1, 2.19.0) No matching distribution found for molecule==

लेकिन यह उस संस्करण को प्राप्त करने में सक्षम होना अच्छा होगा जो वास्तव में डाउनलोड किए बिना और/या इसे dev/null पर इंस्टॉल किए बिना पाइप का उपयोग करके स्थापित किया जाएगा :-)

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

पाइप-टूल्स पाइप पर आधारित एक उपकरण है, जो मुझे विश्वास है कि इस थ्रेड पर लोगों द्वारा पूछी जा रही कुछ चीजों में मदद कर सकता है: https://github.com/jazzband/pip-tools

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

pkg="django"; echo "$pkg" | pip-compile - --output-file - | egrep -i '^'"$pkg"'=' | cut -d '=' -f 3- बस के रूप में मूर्खतापूर्ण है (अधिक मूर्खतापूर्ण यदि आप गिनते हैं कि यह एक और चीज है जिसे आपको स्थापित करना है [आगे मूर्खतापूर्ण अगर आपको python2 समर्थन की आवश्यकता है])

इसके अलावा, पाइप-टूल्स (और पिपेनव) के पूरे बिंदु को सादे पाइप और एक बाधा फ़ाइल के साथ पूरा किया जा सकता है। ( pip install -r reqs -c constraints; pip freeze > constraints )।

pip install पर एक नया विकल्प जोड़ना जो केवल पैकेजों के समाधान तक पाइप चलाएगा और चयनित पैकेजों को प्रिंट करेगा और बाहर निकलेगा (इंस्टॉलेशन को छोड़कर)?

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

मैंने टिप्पणियों का एक पूरा समूह छिपा दिया है, वास्तव में पुरानी टिप्पणियों से लेकर, जिनमें अब प्रासंगिक संदर्भ संलग्न नहीं है, जिनमें "संभावित हैक्स/स्क्रिप्टिंग नगेट्स" शामिल हैं, जो इसके लिए 90%-ऑफ-द-जॉब करते हैं। बाद वाले समूह के लिए, कृपया बाद वाले को यहां पोस्ट करने से बचें - ऐसे अन्य उपयोगकर्ता सहायता फ़ोरम हैं जहां वे सुझाव अधिक उपयुक्त होंगे, न कि इस फ़ोरम पर चर्चा करने के लिए कि टूल में फिक्स को कैसे लागू किया जाए। :)

किसी के लिए भी क्षमा याचना जिसकी वास्तव में अभी भी प्रासंगिक और उपयोगी टिप्पणी छिपी हुई है; मैं वास्तव में बहुत सारी टिप्पणियों के लिए संदर्भ का पता नहीं लगा सका और हो सकता है कि आपका बस संपार्श्विक क्षति में छिपा हो।

चूंकि यह टिकट डिपेंडेंसी रिज़ॉल्वर (#988) के विकास से अवरुद्ध है, मैंने सोचा कि मैं यहां यह उल्लेख करूंगा कि टीम उस विषय पर आगे बढ़ने के लिए समुदाय से मदद की तलाश कर रही है।

हमें उन परिस्थितियों को बेहतर ढंग से समझने की जरूरत है जिनके तहत नया रिज़ॉल्वर विफल हो जाता है, इसलिए जटिल निर्भरता वाले पीआईपी उपयोगकर्ताओं के लिए पूछ रहे हैं:

1. नया रिज़ॉल्वर आज़माएं (संस्करण 20.1 का उपयोग करें, --unstable-feature=resolver चलाएं)
2. इसे तोड़ो: पी
3. समस्या दर्ज करें

आप यहां अधिक जानकारी और अधिक विस्तृत निर्देश प्राप्त कर सकते हैं

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

हम ट्विटर पर बड़े, आम तौर पर मशीन सीखने के अनुप्रयोगों के लिए एक पैकेजिंग विधि विकसित कर रहे हैं जिसे हम "आईपीएक्स" कहते हैं, जिसे तीसरे पक्ष के कोड के बिना भेज दिया जा सकता है जब तक कि उन्हें पहली बार निष्पादित नहीं किया जाता है (जो उनके आकार को बहुत कम कर देता है)। पैंटबिल्ड/पैंट#8793 के मामले में, हम एक निष्पादन योग्य पीएक्स संग्रह उत्पन्न करते हैं जो आवश्यकताओं को हल करने के लिए पीएक्स रनटाइम लाइब्रेरी को कॉल करता है (पीएक्स कवर के तहत पीआईपी निष्पादित करता है)। मैं वर्तमान में एक प्रोटोटाइप पर काम कर रहा हूं जो रनटाइम पर पूर्ण pex/pip समाधान चरण को प्रतिस्थापन के साथ बदल देता है जो केवल यूआरएल को डिस्टर्ब डाउनलोड करने के लिए रिकॉर्ड करता है ( req.link )। यह व्यवहार में बहुत तेज़ है (और इसे बहुत बारीक रूप से कैश किया जा सकता है), क्योंकि "हाइड्रेटेड" pex फ़ाइल बनाने के लिए डाउनलोड और फ़ाइल की प्रतिलिपि पूरी तरह से समानांतर में की जा सकती है।

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

URL को v1 रिज़ॉल्वर की हिम्मत से आउटपुट तक प्रचारित करने के लिए # 7819 में बहुत प्रयास की आवश्यकता थी। यह बहुत कम प्रयास था जब मैंने पिछली बार इसे v2 रिज़ॉल्वर के साथ काम करने की कोशिश की थी। अभी हम शायद --dry-run या resolve कमांड के कुछ प्रयोगात्मक संस्करण को आंतरिक रूप से शिप करने की योजना बना रहे हैं जो डाउनलोड यूआरएल को थूक देता है - अगर हम सफलतापूर्वक ऐसा करते हैं, तो उम्मीद है कि किसी भी को चालू करने में मदद मिलेगी इस बीच --unstable-feature=resolver के साथ शेष मुद्दे! :डी :डी

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

लिंक के लिए आपको धन्यवाद!!

रविवार 24 मई, 2020 को 19:34 बजे त्ज़ु-पिंग चुंग नोटिफिकेशन @github.com
लिखा था:

जैसा कि आपने उल्लेख किया है, लॉक फ़ाइल स्वरूप डिज़ाइन के लिए ऑर्थोगोन्टल है
समाधानकर्ता कार्यान्वयन। हालांकि, इसका मतलब यह भी है कि यह इसके दायरे से बाहर है
वर्तमान पीआईपी परियोजना। विषय पर चर्चा हो चुकी है
https://discuss.python.org/t/structured-exchangeable-lock-file-format-requirements-txt-2-0/876/1
(चेतावनी: बहुत लंबा धागा), लेकिन डेवलपर समय की कमी को देखते हुए
उपलब्ध है, इसका अर्थ यह है कि गंभीर चर्चा की संभावना नहीं होगी
रिज़ॉल्वर कम से कम स्थिर होने से पहले होता है।

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

@cosmicexplorer क्या आपने अभी तक आंतरिक रूप से --dry-run या resolve कमांड के उस प्रयोगात्मक संस्करण को भेज दिया है? अगर ऐसा है तो कैसा चल रहा है?

आपने देखा होगा कि मुझे इस सुविधा में बेहद दिलचस्पी है

कुछ इस तरह का उपयोग करना:

pip install foo==

सभी उपलब्ध संस्करणों की एक सूची देता है (एक वैध pypi उपलब्ध पैकेज के लिए, इस मामले में अणु):

Could not find a version that satisfies the requirement molecule== (from versions: 1.20.1, 1.20.3, 1.21.1, 1.22.0, 1.23.0, 1.25.0, 1.25.1, 2.10.0, 2.10.1, 2.11.0, 2.12.0, 2.12.1, 2.13.0, 2.13.1, 2.14.0, 2.15.0, 2.16.0, 2.17.0, 2.18.0, 2.18.1, 2.19.0) No matching distribution found for molecule==

लेकिन यह उस संस्करण को प्राप्त करने में सक्षम होना अच्छा होगा जो वास्तव में डाउनलोड किए बिना और/या इसे dev/null पर इंस्टॉल किए बिना पाइप का उपयोग करके स्थापित किया जाएगा :-)

अच्छी चाल !! उपयोगी और सुविधाजनक !! वास्तव में प्रभावित करने वाला !!

संभावित हैक्स/स्क्रिप्टिंग नगेट्स ... कृपया बाद के और अधिक पोस्ट करने से बचें - ऐसे अन्य उपयोगकर्ता सहायता फ़ोरम हैं जहां वे सुझाव अधिक उपयुक्त होंगे, न कि टूल में फिक्स को कैसे कार्यान्वित किया जाए, इस पर चर्चा करने के लिए मंच पर नहीं। :)

कुछ नहीं के लिए नहीं, वास्तव में, लेकिन यह उस तरह की चीज होती है जब आप एक बग को बहुत लंबे समय तक रहने देते हैं (मेरे अपने सबसे हाल ही में योगदान किए गए "नगेट" के मामले में 7.56 साल, हालांकि यह अभी भी खुला बग अब 9.25 साल है पुराना)। लोग अपने कामकाज साझा करते हैं।

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

और हाँ, यह वही टिप्पणी भी होती है जो तब होती है जब आपने इस स्टिल-ओपन बग के जवाब में जो किया है वह होता है।

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

आपके कृतार्थ हेतु धन्यवाद। :)

@brainwane @ei8fdb मैं इस मुद्दे को UX के नजरिए से महत्वपूर्ण के रूप में चिह्नित करना चाहता हूं - #8377 से संबंधित

मेरी समझ के आधार पर उच्च स्तरीय सारांश:

• नए रिज़ॉल्वर के साथ, पाइप कम अनुमेय होगा और परस्पर विरोधी निर्भरताएँ स्थापित करने से इनकार करेगा ( ResolutionImpossible )
• निर्भरता संघर्ष निर्भरता वृक्ष में कहीं भी मौजूद हो सकता है
• मौजूदा उपकरण (पिपडेप्ट्री पाइप-संघर्ष-चेकर) केवल वे पैकेज दिखाते हैं जो पहले से स्थापित हैं, न कि वे जिन्हें अनुरोध किया गया है, लेकिन विफल
• वर्तमान में उपयोगकर्ताओं के लिए यह पता लगाने का कोई तरीका नहीं है कि पैकेज स्थापित होने से पहले _निर्भरता संघर्ष कहां है, या जब कोई ResolutionImpossible त्रुटि होती है (प्रत्येक प्रोजेक्ट की निर्भरता का मैन्युअल रूप से निरीक्षण करने के अलावा)

संक्षेप में, हमें उपयोगकर्ताओं को उनकी शीर्ष स्तर की आवश्यकताओं (यानी requirements.txt में निर्दिष्ट पैकेज या सीधे कमांड लाइन में दर्ज किए गए पैकेज) के आधार पर संभावित निर्भरता संघर्षों का पता लगाने के लिए एक तरीके की आवश्यकता है।

यदि हम ऐसा करने का निर्णय लेते हैं, तो प्रस्तावित ध्वज नाम ( --dry-run ) पर शोध/चर्चा की जानी चाहिए।

@uranusjr @pfmoore - अगर मुझे कुछ भी गलत लगा है, या हमारी चर्चा के आधार पर कुछ छूट गया है तो कृपया मुझे सुधारें। धन्यवाद

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

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

यह pip resolve कमांड का रूप भी ले सकता है।

pip resolve वह है जो सबसे अधिक उम्मीद करेगा, कृपया इसे कॉल करें कि 😄 यह अंततः अपने स्वयं के झंडे के लिए भी अनुमति देगा।

स्पष्टीकरण @pfmoore के लिए धन्यवाद। उपयोगकर्ता के दृष्टिकोण से, मुझे यकीन नहीं है कि --dry-run का कितना उपयोग --dry-run resolve बिना है?

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

तो, कल्पना करें कि कोई उपयोगकर्ता --dry-run चलाता है ... हम प्रतिक्रिया में कुछ इस तरह शामिल कर सकते हैं:

निर्भरता संघर्ष का पता चला। पाइप d 1.0 और c 1.0 को स्थापित करने में सक्षम नहीं होगा।
संघर्ष के कारण होता है:
डी 1.0 ई == 2.0 . पर निर्भर करता है
सी 1.0 ई == 1.0 . पर निर्भर करता है
निर्भरता वृक्ष का निरीक्षण करने के लिए pip resolve चलाएँ।

हम pip resolve को ResolutionImpossible त्रुटि संदेश (#8377 देखें) में पुन: उपयोग कर सकते हैं, जो एक बड़ी जीत होगी।

@pradyunsg क्या हमारे पास pip resolve के लिए एक अलग टिकट है?

@nlhkabu https://github.com/pypa/pip/issues/7819

साथ ही, स्पष्ट होने के लिए, मेरा मानना ​​​​है कि pip resolve के लिए इच्छित उपयोग केस या तो (सफलता मानते हुए) है:

1. आउटपुट को किसी फ़ाइल में पुनर्निर्देशित करें (जो आमतौर पर प्रतिबद्ध होगा), या
2. अन्य उपकरण आउटपुट का उपयोग/पार्स करेंगे

ट्विटर के लिए, #7819 में वर्णित "आईपीएक्स" टूल का उपयोग करके, हम pip resolve कमांड का उपयोग करके निष्पादन योग्य पीएक्स फाइलें बना रहे हैं जो कुछ भी डाउनलोड करने के बजाय सभी हल किए गए वितरण के लिए डाउनलोड यूआरएल आउटपुट करेगा (अभी तक उत्पादन में उपयोग नहीं किया जा रहा है) ) यह, कई अन्य अनुकूलन जैसे #8448 के साथ, सेकंड के भीतर इन ipex फ़ाइलों को बनाने की अनुमति देता है। ये ipex फ़ाइलें तब सभी वितरण आउटपुट को pip resolve कमांड से डाउनलोड करती हैं, जब वे पहली बार निष्पादित होते हैं, उसी डेटासेंटर के भीतर से - यह ipex फ़ाइलों को गीगाबाइट्स के बजाय मेगाबाइट होने की अनुमति देता है, जो अपलोड समय में सुधार करता है कई क्षेत्रों से।

इसलिए हम मूल रूप से pip resolve आउटपुट के एक json संस्करण को pex आर्काइव में एक फाइल के रूप में एम्बेड करते हैं, और हमारे पास एक बूटस्ट्रैप स्क्रिप्ट है जिसे समानांतर में वितरण को डाउनलोड करने के लिए पढ़ा जाता है।

इस पर किसी भी अद्यतन?

किसी को यह पता लगाने की जरूरत है कि पहले संकल्प परिणाम कैसे प्रस्तुत किया जाए। रिज़ॉल्वर कार्य में शामिल AFAIK पाइप अनुरक्षक वर्तमान में रिज़ॉल्वर को बेहतर बनाने के लिए प्रयास कर रहे हैं, इसलिए इसे आगे बढ़ने के लिए कुछ बाहरी मदद की आवश्यकता होगी।

अगर मैं गलत हूं तो कृपया मुझे सुधारें, लेकिन निम्नलिखित सत्य प्रतीत होता है:

• पायथन पैकेज को स्थापित करने में इसके setup.py को निष्पादित करना शामिल है।
• --dry-run विकल्प के बिना, यह जानने का कोई आसान और विश्वसनीय तरीका नहीं है कि पाइप का रिज़ॉल्वर कौन से संकुल को संस्थापित करने के लिए चुनेगा।

इसलिए, मुझे ऐसा लगता है कि pip install चलाने का अर्थ है किसी की मशीन पर पीईपीआई पैकेजों के मनमाने ढंग से चयन से कोड चलाने के लिए सहमति देना, इसे ऑडिट करने का एक आसान और विश्वसनीय तरीका नहीं है। वह चयन व्यक्तिगत पैकेज लेखकों की निर्भरता विकल्पों और सुरक्षा प्रथाओं पर पुनरावर्ती रूप से निर्भर करता है।

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

यहां तक ​​​​कि --dry-run के साथ, यह संभावना है कि pip को संकुल के लिए बिल्ड बैकएंड चलाने की आवश्यकता होगी (जिसमें setuptools के लिए, setup.py चलाना शामिल है) जिसमें पहिये नहीं हैं।