Pip: 19.0 में -no-cache-dir का उपयोग करते समय जोर देना

उसी के साथ हो रही बात:
Python v3.6.8
pip version 18.1
पर
Ubuntu:latest छवि।

@snstanton आप किस आधार छवि का उपयोग कर रहे हैं? मैं पाइप v18.1 पर भी इसी तरह का मुद्दा देख रहा हूं

मुझे एक ही मुद्दा मिला है।
मेरी तरफ से ऐसा लगता है कि इससे कोई फर्क नहीं पड़ता कि मैं किस पैकेज / वितरण को स्थापित करने की कोशिश करता हूं

मैं इसे --no-cache-dir सेट के बिना भी देख रहा हूँ। यह उन सभी पैकेजों के लिए होता है जिन्हें मैं स्थापित करने का प्रयास करता हूं, भले ही वे पहले से ही स्थापित हों।

• पाइप संस्करण: 19.0
• पायथन संस्करण: 3.6.0
• OS: Ubuntu 14.04.4 LTS (GNU / Linux 3.13.0-91-जेनेरिक x86_64)

मुझे ध्यान देना चाहिए कि मेरे मामले में मैं pip sudo -H और bash -l -c संयोजन के साथ चल रहा हूँ।

$ sudo -H bash -l -c  "/data/virtualenvs/events_beta/bin/pip install hypothesis"
Looking in indexes: https://pypi.org/simple, http://pypi.lan.cogtree.com/cogtree/simple/
Collecting hypothesis
  Downloading http://pypi.lan.cogtree.com/cogtree/simple/hypothesis/hypothesis-4.1.0-py3-none-any.whl (238kB)
    100% |████████████████████████████████| 245kB 120.5MB/s
Requirement already satisfied: attrs>=16.0.0 in /data/virtualenvs/events_beta/lib/python3.6/site-packages (from hypothesis) (18.2.0)
Exception:
Traceback (most recent call last):
  File "/data/virtualenvs/events_beta/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 176, in main
    status = self.run(options, args)
  File "/data/virtualenvs/events_beta/lib/python3.6/site-packages/pip/_internal/commands/install.py", line 346, in run
    session=session, autobuilding=True
  File "/data/virtualenvs/events_beta/lib/python3.6/site-packages/pip/_internal/wheel.py", line 848, in build
    assert building_is_possible
AssertionError

बिना -l bash -c bash -l -c ।

$ sudo -H bash -c  "/data/virtualenvs/events_beta/bin/pip install hypothesis"
Collecting hypothesis
  Downloading https://files.pythonhosted.org/packages/89/7b/d6206dcde963139daa03a1d85b0c3428cb3ebf2ae8de3244b14a63e22680/hypothesis-4.1.0.tar.gz (180kB)
    100% |████████████████████████████████| 184kB 33.7MB/s
Requirement already satisfied: attrs>=16.0.0 in /data/virtualenvs/events_beta/lib/python3.6/site-packages (from hypothesis) (18.2.0)
Building wheels for collected packages: hypothesis
  Building wheel for hypothesis (setup.py) ... done
  Stored in directory: /root/.cache/pip/wheels/10/12/eb/4ab734432e8466d545c8501f531458845b45e8c4427d5367f9
Successfully built hypothesis
Installing collected packages: hypothesis
Successfully installed hypothesis-4.1.0

ध्यान से, अगर मैं sudo या bash सभी में शामिल हो, तो भी यह एक ही त्रुटि के साथ विफल रहता है, इसलिए ऐसा लगता है कि यह कुछ अजीब अनुमतियाँ समस्या है।

कुछ स्थितियों के लिए एक और समाधान

जो लोग इस बग से टकराते हैं, क्योंकि वर्चुअनव स्वचालित रूप से पाइप के नवीनतम संस्करण को स्थापित कर रहा है, आप इसके चारों ओर वर्चुअनव --no-download विकल्प दे सकते हैं, या VIRTUALENV_NO_DOWNLOAD=1 ।

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

यह विषाक्त के साथ भी काम करता है: VIRTUALENV_NO_DOWNLOAD=1 tox ।

अगर यह पहले से ही स्थापित है, तो यह उसी त्रुटि के साथ भी विफल रहता है:

gregory.starck<strong i="6">@canon</strong>:~/tmp$ ./venv/bin/pip install --no-cache-dir six ; echo $?
Looking in indexes: http://pypi:3141/root/ax/+simple/
Requirement already satisfied: six in ./venv/lib/python3.6/site-packages (1.12.0)
Exception:
Traceback (most recent call last):
  File "/home/gregory.starck/tmp/venv/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 176, in main
    status = self.run(options, args)
  File "/home/gregory.starck/tmp/venv/lib/python3.6/site-packages/pip/_internal/commands/install.py", line 346, in run
    session=session, autobuilding=True
  File "/home/gregory.starck/tmp/venv/lib/python3.6/site-packages/pip/_internal/wheel.py", line 848, in build
    assert building_is_possible
AssertionError
2
gregory.starck<strong i="7">@canon</strong>:~/tmp$

उसी मुद्दे में भाग गया। अब के लिए एक फिक्स के रूप में पाइप संस्करण को पिनिंग समाप्त किया।

pip install --upgrade pip==18.1

समस्या मुखर होने के साथ है, इसलिए env PYTHONOPTIMIZE = 1 (या पैरामीटर -O के साथ) सेट करने से यह त्रुटि दूर हो जाती है।
बस इसका परीक्षण किया।
यह वर्कअराउंड काम करता है क्योंकि अजगर कोड को सभी चीजों में से एक के रूप में हटाने का अनुकूलन करता है।
= 2 (या -OO) के लिए मत जाओ, क्योंकि इससे डोकस्ट्रिंग्स को हटा दिया जाता है और अन्य ट्रेसबैक दिखाई देंगे - कुछ कोड उन पर काम करना चाहते हैं।

ऐसा लगता है कि किसी को पता था कि यह एक मुद्दा ( स्रोत ) हो सकता है:

        # TODO: This check fails if --no-cache-dir is set. And yet we
        #       might be able to build into the ephemeral cache, surely?
        building_is_possible = self._wheel_dir or (
            autobuilding and self.wheel_cache.cache_dir
        )
        assert building_is_possible

https://github.com/pypa/pip/pull/5884 ऐसा लगता है कि यह एक संबंधित परिवर्तन है जो इसका कारण हो सकता है?

पाइप मेंटेनर की तरह लगता है कि हाल ही में 19 रिलीज इस ब्रेकिंग परिवर्तन को संबोधित करने के लिए रोलबैक करना चाहिए?
19.0 जारी नोट: https://github.com/pypa/pip/blob/master/NEWS.rst#190 -2019-01-22

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

TODO टिप्पणी जोड़ने वाले PR ने भी इस टिप्पणी का जवाब दिया है: https://github.com/pypa/pip/pull/5743/files#r215832743

उस टिप्पणी के आधार पर और ऊपर दिए गए टिप्पणीकार ने भी कहा कि PYTHONOPTIMIZE=1 करने से त्रुटि दूर हो जाती है, ऐसा लगता है जैसे केवल दावे को हटाना सही फिक्स हो सकता है (रोलिंग बैक के सवाल से स्वतंत्र)।

हाँ, जब मैं उस मुखर को हटाता हूँ, तो पैकेज --no-cache-dir साथ ठीक-ठाक स्थापित हो जाता है। उस मामले में, यह कहना है कि वह है Running setup.py install के बजाय Building wheel sdist संकुल के लिए।

मेरी परियोजनाओं के लिए भी यही हो रहा है। मैं डॉकियर छवियों में FROM ubuntu:bionic और FROM centos:centos7 हूं, जहां मैं स्रोत से पायथन 3 स्थापित कर रहा हूं (यहां एक Gist है जो उन दोनों डॉकर छवियों के लिए एक असफल उदाहरण प्रदर्शित करता है कि यह घटना में है सहायक हो सकता है)। Gist में उदाहरण में requirements.txt के लिए और

$ pip3 install --upgrade pip setuptools wheel
Requirement already up-to-date: pip in /usr/lib/python3.6/site-packages (19.0)
Requirement already up-to-date: setuptools in /usr/lib/python3.6/site-packages (40.6.3)
Requirement already up-to-date: wheel in /usr/lib/python3.6/site-packages (0.32.3)

फिर

$ pip3 install --upgrade --no-cache-dir -r requirements.txt

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

Exception:
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 176, in main
    status = self.run(options, args)
  File "/usr/lib/python3.6/site-packages/pip/_internal/commands/install.py", line 346, in run
    session=session, autobuilding=True
  File "/usr/lib/python3.6/site-packages/pip/_internal/wheel.py", line 848, in build
    assert building_is_possible
AssertionError

परंतु

$ pip3 install --upgrade -r requirements.txt

उम्मीद के मुताबिक काम करता है।

मैं इसे विशेष रूप से tox + docker + ENV PIP_NO_CACHE_DIR=off साथ मार रहा हूं

ऑटो-अपडेट से पाइप को रोकने के लिए मेरा वर्कअराउंड tox-virtualenv-no-download प्लगइन का उपयोग करना है

छवियों को छोटा रखने के लिए हमारे पास डॉकर के अंदर --no-cache-dir भी हैं। हमारा वर्कअराउंड --cache-dir=/pipcache और फिर rm -rf /pipcache एक ही RUN स्टेप में हो गया है ताकि यह इमेज में कभी खत्म न हो।

सॉफ्टवेयर विकास कठिन है और इस तरह बग हमेशा होने वाले हैं। निश्चित रूप से किसी को भी इस घटना के लिए pip मेंटेनर्स या योगदानकर्ताओं को दोष नहीं देना चाहिए।

हालाँकि, मैं यह सुझाव दूंगा कि यह बग पाइप की टीम की ओर से किसी प्रकार के पोस्टमार्टम विश्लेषण का गुणन करता है, क्योंकि इस बग के लिए (छूटे हुए) अवसरों की संख्या सामान्य रिलीज़ में फिसलने से पहले पकड़ी गई थी। उदाहरण के लिए:

• --no-cache-dir जैसी कोर कार्यक्षमता का स्वचालित परीक्षण
• प्री-कमिट, प्री-मर्ज, या प्री-रिलीज़ चेक जो झंडा (या निषेध) TODO s है
• पीआर में सभी अनसुलझे समीक्षा टिप्पणियों की (मानव) पूर्व-मर्ज समीक्षा
• रिलीज की प्रक्रिया में बदलाव - पहले बीटा रिलीज क्यों नहीं किया गया और फिर सामान्य रिलीज से कई हफ्ते पहले इंतजार करना पड़ा?
• आदि

एक पोस्टमॉर्टम से यह सुनिश्चित करने के लिए कई उपयोगी मदद मिल सकती है कि सॉफ्टवेयर उस पायथन परियोजना के मूल रूप में pip जो भविष्य में इस परिमाण के कीड़े के साथ जहाज नहीं करता है।

मैं इस बग को दोहरा सकता हूं। हटाने के लिए - इसे कैश फिक्स करता है। चूँकि मैं इसे अपनी डॉक छवि में नहीं चाहता हूँ इसलिए मैं प्रस्तावित समाधान

यह # 6166 अंक की नकल की तरह दिखता है

त्वरित और आसान प्रजनन Dockerfile:

FROM buildpack-deps:buster
ENV LANG C.UTF-8
ENV LC_ALL C.UTF-8
RUN apt-get update && apt-get install -y --no-install-recommends python3-dev && rm -rf /var/lib/apt/lists/*
RUN curl https://bootstrap.pypa.io/get-pip.py | python3 - --no-cache-dir

बस दावे को हटाने के लिए सही समाधान हो सकता है

बिल्कुल नहीं - मुझे लगता है कि हमें गैर-खेप के निर्माण के लिए इसे वहां रखना चाहिए। एक बार नाश्ते के साथ करने पर, मैं बगफिक्स पीआर फाइल करूंगा। :)

@pradyunsg एक विफल परीक्षा के लिए मेरे पीआर की जाँच करें

मेरे लिए, पाइप v19.0 कुछ भी स्थापित करने में विफल रहेगा यदि --no-cache (या --no-cache-dir ) विकल्प का उपयोग नहीं किया जाता है।

मैंने इस मुद्दे के लिए # 6171 को बगफिक्स के रूप में दर्ज किया है। क्या इस थ्रेड के लोग उस PR को आज़मा सकते हैं और सत्यापित कर सकते हैं कि यह वास्तव में इस समस्या को हल करता है?

पुनश्च: इस मुद्दे को जल्दी से ठीक करने में सहायता के लिए PR दाखिल करने के लिए @tgs का धन्यवाद! :)

wfm, फिक्स के लिए धन्यवाद!

$ pip install pip --upgrade
Requirement already up-to-date: pip in ./venv/lib/python3.6/site-packages (19.0)
$ pip install --no-cache-dir pip
Requirement already satisfied: pip in ./venv/lib/python3.6/site-packages (19.0)
Exception:
Traceback (most recent call last):
  File "/tmp/venv/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 176, in main
    status = self.run(options, args)
  File "/tmp/venv/lib/python3.6/site-packages/pip/_internal/commands/install.py", line 346, in run
    session=session, autobuilding=True
  File "/tmp/venv/lib/python3.6/site-packages/pip/_internal/wheel.py", line 848, in build
    assert building_is_possible
AssertionError
$ pip install git+https://github.com/pradyunsg/pip@fix/pep-517-building-assertion
Collecting git+https://github.com/pradyunsg/pip@fix/pep-517-building-assertion
  Cloning https://github.com/pradyunsg/pip (to revision fix/pep-517-building-assertion) to ./pip-req-build-g_3qep31
Branch 'fix/pep-517-building-assertion' set up to track remote branch 'fix/pep-517-building-assertion' from 'origin'.
Switched to a new branch 'fix/pep-517-building-assertion'
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
    Preparing wheel metadata ... done
Building wheels for collected packages: pip
  Building wheel for pip (PEP 517) ... done
  Stored in directory: /tmp/pip-ephem-wheel-cache-sb1_muik/wheels/bd/86/cd/7688dba746eabc598fb37d4a93e2ff9bd05a6d9f907ee7b6cd
Successfully built pip
Installing collected packages: pip
  Found existing installation: pip 19.0
    Uninstalling pip-19.0:
      Successfully uninstalled pip-19.0
Successfully installed pip-19.1.dev0
$ pip install --no-cache-dir astpretty  # downloads a wheel
Collecting astpretty
  Downloading https://files.pythonhosted.org/packages/9d/10/cb0c3a3edb16f45be05bdba7f37798fcddb8cf085def8cb6e62b2ad7c711/astpretty-1.4.1-py2.py3-none-any.whl
Installing collected packages: astpretty
Successfully installed astpretty-1.4.1
$ pip install --no-cache-dir simplejson  # requires building
Collecting simplejson
  Downloading https://files.pythonhosted.org/packages/e3/24/c35fb1c1c315fc0fffe61ea00d3f88e85469004713dab488dee4f35b0aff/simplejson-3.16.0.tar.gz (81kB)
    100% |████████████████████████████████| 81kB 1.0MB/s 
Installing collected packages: simplejson
  Running setup.py install for simplejson ... done
Successfully installed simplejson-3.16.0

मुझे आशा है कि जल्द ही PR6171 का विलय होगा और संस्करण 19.0.1 जारी होगा

लोगों को वास्तव में CI में पाइप डालना चाहिए जैसे आप किसी अन्य पैकेज या निर्भरता, IMO के लिए करते हैं। अन्यथा, आपके पास प्रजनन क्षमता और अचानक टूटने का जोखिम नहीं है। पिन करके, आप पहले से चीजों की जांच कर सकते हैं और अपनी गति से अपग्रेड कर सकते हैं।

लोगों को वास्तव में CI में पाइप डालना चाहिए जैसे आप किसी अन्य पैकेज या निर्भरता, IMO के लिए करते हैं। अन्यथा, आपके पास प्रजनन क्षमता और अचानक टूटने का जोखिम नहीं है। पिन करके, आप पहले से चीजों की जांच कर सकते हैं और अपनी गति से अपग्रेड कर सकते हैं।

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

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

इस तरह की घटनाएं उस विश्वास को मिटा देती हैं। टूटी हुई सीआई बिल्ड वास्तविक मुद्दा नहीं है (जैसा कि आप कहते हैं, आपको या तो pip CI बिल्ड करना होगा या जागरूक होना चाहिए कि आप क्या जोखिम में डाल रहे हैं), लेकिन एक लक्षण हैं - या बल्कि, एक सहसंबद्ध चेतावनी - यह विश्वास खत्म हो गया।

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

हाँ, इस तरह की घटनाएं विश्वास बनाने में मदद नहीं करती हैं। हमारे पास यह पता लगाने के लिए एक पोस्टमार्टम होगा कि इनसे कैसे बचें (हम ऐसा हर रिलीज़ के बाद करते हैं क्योंकि इसमें हमेशा सुधार की गुंजाइश होती है)।

(ज्यादातर) उचित प्रवचन को बनाए रखने और रचनात्मक टिप्पणियों के लिए धन्यवाद! आमतौर पर, चीजें हमारे लिए बहुत अधिक संक्षारक होती हैं जब इस तरह का कोई मुद्दा होता है। :)

कोई भी कम नहीं है, कुछ अन्य बग रिपोर्ट देखने के लिए है और हमारे पास 19.0.1 जल्द ही पर्याप्त होगा।

मुझे लगता है कि यहां महत्वपूर्ण बात यह है कि यह उजागर हुआ है कि हमारे पास --no-cache-dir तहत निर्माण के लिए पर्याप्त परीक्षण नहीं हैं। उस क्षेत्र में अतिरिक्त परीक्षण इस तरह के प्रतिगमन से बचने में बहुत बड़ी मदद होगी, और आम तौर पर "कुंजी" की कार्यक्षमता का परीक्षण किया जाता है, की समीक्षा सहायक होगी।

एक पाइप मेंटेनर के रूप में, मैं कहूंगा कि मुझे एक समस्या यह है कि लोग जानते हैं कि "की" कार्यक्षमता को क्या माना जाता है। व्यक्तिगत रूप से, मैंने --no-cache-dir का मूल्य काफी आला माना होगा, तो जाहिर है कि इस मामले में मेरा अंतर्ज्ञान विश्वसनीय नहीं है :-) इसलिए इस तरह की प्रतिक्रिया विशेष रूप से मूल्यवान है।

मुझे लगता है कि यह इस बग के लिए जल्द ही 19.0.1 जारी किया जा सकता है, आखिरकार, यह महत्वपूर्ण और जरूरी है। एक और बग रिपोर्ट दिन के बाद 19.0.2 में हल कर सकती है।

एक पाइप मेंटेनर के रूप में, मैं कहूंगा कि मुझे एक समस्या यह है कि लोग जानते हैं कि "की" कार्यक्षमता को क्या माना जाता है। व्यक्तिगत रूप से, मैंने --no-cache-dir का मूल्य काफी आला माना होगा, तो जाहिर है कि इस मामले में मेरा अंतर्ज्ञान विश्वसनीय नहीं है :-) इसलिए इस तरह की प्रतिक्रिया विशेष रूप से मूल्यवान है।

एकमात्र कारण है कि मैं --no-cache-dir उपयोग करता हूं, mpi4py स्थापित करने के लिए है।
इस तरह, मैं यह सुनिश्चित कर सकता हूं कि इसे स्थापित करने से पहले इसे फिर से डाउनलोड और पुनर्निर्मित किया जाए, यह सुनिश्चित करते हुए कि मेरे एमपीआई वितरण में किए गए किसी भी बदलाव को ध्यान में रखा गया है।

यहाँ एक ही मुद्दा, हमारे CI सिस्टम के बाहर इसे पुन: पेश करने में सक्षम। वर्कअराउंड के रूप में हमने 18.1.0 और सब कुछ काम करने के लिए डाउनग्रेड किया है:

pip install pip==18.1.0

आशा है और जल्द ही उन्नयन होगा।

मैं इस्तेमाल करूँगा:

pip install "pip!=19.0"

उम्मीद है 19.1 तय है :)

मुझे लगता है कि हमारे पास एक 19.0.1 अपेक्षाकृत जल्द ही उभरते मुद्दों के लिए सुधार होगा।

मैं उत्सुक हूँ अगर --no-use-pep517 के साथ --no-cache-dir इस मुद्दे के लिए एक और काम है, क्योंकि यह अन्य PEP 517 से संबंधित मुद्दे के लिए है: https://github.com/pypa/pip / मुद्दों / 6163 # जारी करने -456772043

एक पाइप मेंटेनर के रूप में, मैं कहूंगा कि मुझे एक समस्या यह है कि लोग जानते हैं कि "की" कार्यक्षमता को क्या माना जाता है। व्यक्तिगत रूप से, मैंने मान लिया होगा कि -नो-कैश-डीआईआर काफी आला था, इसलिए स्पष्ट रूप से मेरा अंतर्ज्ञान इस मामले में विश्वसनीय नहीं है :-) इसलिए इस तरह की प्रतिक्रिया विशेष रूप से मूल्यवान है।

एफडब्ल्यूआईडब्ल्यू: मैं डॉकर चित्रों का निर्माण करते समय --no-cache-dir बहुत बार उपयोग करता हूं, ताकि किसी भी कैश cruft के आसपास के वातावरण में बचे रहने की संभावना को रोका जा सके जहां यह उपयोगी नहीं होगा।

लोगों को वास्तव में CI में पाइप डालना चाहिए जैसे आप किसी अन्य पैकेज या निर्भरता, IMO के लिए करते हैं। अन्यथा, आपके पास प्रजनन क्षमता और अचानक टूटने का जोखिम नहीं है। पिन करके, आप पहले से चीजों की जांच कर सकते हैं और अपनी गति से अपग्रेड कर सकते हैं।

कई वातावरणों में पाइप निर्भरता नहीं है। यह virtualenv बनाते समय स्थापित किया गया है।

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

पाइप 19.0.1 इस समस्या के समाधान के साथ है।

मैं नए 19.0.1 संस्करण को देखने के लिए उत्साहित था, लेकिन फिर भी एक मुद्दा रहा। मैं --no-cache-dir साथ एक डॉकर छवि भी बना रहा हूं जो पाइप <19.0 के साथ ठीक काम करता है। किसी और को यह हो रही है?

Exception:
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 176, in main
    status = self.run(options, args)
  File "/usr/lib/python3.6/site-packages/pip/_internal/commands/install.py", line 346, in run
    session=session, autobuilding=True
  File "/usr/lib/python3.6/site-packages/pip/_internal/wheel.py", line 886, in build
    assert have_directory_for_build
AssertionError

मैं नए 19.0.1 संस्करण को देखने के लिए उत्साहित था, लेकिन फिर भी एक मुद्दा रहा। मैं --no-cache-dir साथ एक डॉकर छवि भी बना रहा हूं जो पाइप <19.0 के साथ ठीक काम करता है। किसी और को यह हो रही है?

फिक्स मेरे लिए 19.0.1 के साथ काम कर रहा है - मुझे संदेह है कि आपको एक डॉक लेयर कैश मिला है जो आपको भ्रमित कर रहा है? - pip --version की जाँच करें कि आप किस संस्करण पर हैं

मेरे पास मेरे सभी डॉकर फ़ाइलों में एक पायथन और पाइप संस्करण की जांच है, और यह सही ढंग से 19.0.1 की रिपोर्ट करता है।

@ वाल्टर ने आज सुबह स्क्रैच से अपनी डस्ट में मेरी को फिर से बनाया और चीजें वहां v19.0.1 साथ ठीक काम कर रही हैं। क्या आप अपने डॉकफाइल को एक जिस्ट में भी साझा कर सकते हैं ताकि हम सभी इसे देख सकें?

बस फिर से पक्का करने के लिए सब कुछ साफ कर दिया। यहाँ Dockerfile और मेरा बिल्ड आउटपुट है ।

उपयोग किए जाने वाले docker कमांड के लिए बिल्ड आउटपुट पर मेरा नोट देखें।

वहाँ pip3 के लिए एक तय है? मुझे मिला त्रुटि ...

> pip3 install --upgrade 'pip>=19.01' setuptools

  Could not find a version that satisfies the requirement pip>=19.01 (from versions: 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, 0.8.3, 1.0, 1.0.1, 1.0.2, 1.1, 1.2, 1.2.1, 1.3, 1.3.1, 1.4, 1.4.1, 1.5, 1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 6.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, 6.0.5, 6.0.6, 6.0.7, 6.0.8, 6.1.0, 6.1.1, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.1.0, 7.1.1, 7.1.2, 8.0.0, 8.0.1, 8.0.2, 8.0.3, 8.1.0, 8.1.1, 8.1.2, 9.0.0, 9.0.1, 9.0.2, 9.0.3, 10.0.0b1, 10.0.0b2, 10.0.0, 10.0.1, 18.0, 18.1, 19.0)
No matching distribution found for pip>=19.01
You are using pip version 10.0.1, however version 19.0 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

@MrAtheist आपके पास एक छोटा टाइपो / एक दशमलव गुम है। पैच रिलीज़ 19.0.1 लेकिन आपके पास 19.01 लिखा है।

मेरी गलती है, लेकिन किसी भी तरह से, संभव संस्करण 19.0.1 सूचीबद्ध नहीं है ... (_ (¯) _ / but

@Dmulter की तरह मैं इस मुद्दे को अभी भी अनसुलझा पा रहा हूं। निर्माण से निकालें:

. venv/bin/activate;  python -m pip install --upgrade pip; python -m pip install ndg_httpsclient; python -m pip install . -i https://xxxx.yyyy.com/simple --upgrade --no-cache-dir flask
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.
Requirement already up-to-date: pip in ./venv/lib/python2.7/site-packages (19.0.1)
...
Requirement already satisfied, skipping upgrade: pycparser in ./venv/lib/python2.7/site-packages (from cffi>=1.1->bcrypt>=3.1.3->paramiko<3.0,>=1.10->Fabric==1.14.0->conference-gll-load-test===0.0.1-SNAPSHOT) (2.19)
Exception:
Traceback (most recent call last):
  File "/mnt/jenkins/workspace/venv/local/lib/python2.7/site-packages/pip/_internal/cli/base_command.py", line 176, in main
    status = self.run(options, args)
  File "/mnt/jenkins/workspace/venv/local/lib/python2.7/site-packages/pip/_internal/commands/install.py", line 346, in run
    session=session, autobuilding=True
  File "/mnt/jenkins/workspace/venv/local/lib/python2.7/site-packages/pip/_internal/wheel.py", line 886, in build
    assert have_directory_for_build
AssertionError
make: *** [install] Error 2

इससे पहले थ्रेड में मैंने पूछा था कि क्या --no-use-pep517 के साथ --no-cache-dir लोगों के लिए काम करता है, लेकिन मुझे कोई उत्तर नहीं मिला। उन लोगों के लिए जो अभी भी विकल्प का अनुभव कर रहे हैं, क्या आप कोशिश कर सकते हैं?

--no-use-pep517 विकल्प जोड़ने से मेरे लिए समस्या ठीक हो गई। आशा है कि संकीर्ण चीजों को कम करने में मदद करता है।

एक virtualenv में मेरे लिए 19.0.1 पाइप काम कर रहा है। लेकिन जेनकिंस (शाइनिंग पांडा) के अंदर यह अभी भी विफल है। --No-use-pep517 को जोड़ना समस्या को ठीक करता है

मैं फिर से खोल रहा हूं क्योंकि कुछ लोग अभी भी उसी मुद्दे का सामना कर रहे हैं।

मैं यह भी पुष्टि कर सकता हूं कि 19.0.1 पाइप में अपग्रेड करने के बाद --no-use-pep517 ने मेरे लिए मुद्दा तय किया था।

जब भी पाइप को नया संस्करण मिलता है तो उन सभी परियोजनाओं को क्यों अनुकूलित करना पड़ता है?

@Pradyunsg के अनुरोध पर , मैंने 19.0.1 रिलीज में AssertionError लिए विशिष्ट (https://github.com/pypa/pip/issues/6197) एक नया अंक खोला है, क्योंकि यह संकरा है गुंजाइश में और नई जांच की आवश्यकता होगी। इसलिए मैं इस मुद्दे को याद कर रहा हूं।

उसी मुद्दे में भाग गया। अब के लिए एक फिक्स के रूप में पाइप संस्करण को पिनिंग समाप्त किया।

pip install --upgrade pip==18.1

या आपका FROM python:3.6-alpine FROM python:3.6.7-alpine बदल सकता है

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