Pip: التأكيد عند استخدام - no-cache-dir في 19.0

يحدث نفس الشيء مع:
Python v3.6.8
pip version 18.1
على
Ubuntu:latest .

snstanton ما الصورة الأساسية التي تستخدمها؟ أرى مشكلة مماثلة في النقطة v18.1 أيضًا

لدي نفس المشكلة بالضبط.
من جانبي ، يبدو أنه لا يهم الحزمة / التوزيع الذي أحاول تثبيته

أرى هذا حتى بدون تعيين --no-cache-dir . يحدث ذلك لجميع الحزم التي أحاول تثبيتها ، حتى لو كانت مثبتة بالفعل.

• إصدار النقطة: 19.0
• إصدار Python: 3.6.0
• نظام التشغيل: Ubuntu 14.04.4 LTS (GNU / Linux 3.13.0-91-generic 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 متورطًا على الإطلاق ، فإنه لا يزال يفشل مع نفس الخطأ ، لذلك يبدو أنه ربما يكون مشكلة أذونات غريبة.

حل آخر لبعض المواقف

بالنسبة للأشخاص الذين أصيبوا بهذا الخطأ لأن Virtualenv يقوم تلقائيًا بتثبيت أحدث إصدار من النقطة ، يمكنك التغلب عليه من خلال منح virtualenv الخيار --no-download ، أو تعيين VIRTUALENV_NO_DOWNLOAD=1 .

لكن اعلم أن هذا قد يمنحك نسخة قديمة جدًا من النقطة ، اعتمادًا على آخر مرة قمت فيها بترقية virtualenv.

يعمل هذا أيضًا مع Tox: 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) يجعل هذا الخطأ يختفي.
فقط اختبرته.
يعمل هذا الحل لأن python يحسن الكود ويزيل جميع التأكيدات كأحد الأشياء.
لا تذهب إلى = 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 في جميع الأماكن :)

يحتوي PR الذي يضيف تعليق TODO أيضًا على هذا التعليق ردًا: https://github.com/pypa/pip/pull/5743/files#r215832743

بناءً على هذا التعليق وأيضًا المعلق أعلاه الذي قال إن تمرير PYTHONOPTIMIZE=1 يجعل الخطأ يختفي ، يبدو أن إزالة التأكيد ببساطة قد يكون الحل الصحيح (بغض النظر عن مسألة التراجع).

نعم ، عندما أحذف هذا التأكيد ، يتم تثبيت الحزم بشكل جيد مع --no-cache-dir . في هذه الحالة ، تقول أنها Running setup.py install بدلاً من Building wheel لحزم sdist.

هذا يحدث أيضًا لمشاريعي. يمكنني إعادة إنتاج هذا في صور Docker التي تم إنشاؤها FROM ubuntu:bionic و FROM centos:centos7 حيث أقوم بتثبيت Python 3 من المصدر (هنا Gist يوضح مثالاً فاشلاً لكل من صور Docker هذه في حالة حدوث ذلك قد يكون مفيدًا). بالنسبة إلى requirements.txt في المثال الموجود في Gist و

$ 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 في عمليات التثبيت الخاصة بنا داخل Docker لإبقاء الصور صغيرة. كان حلنا هو --cache-dir=/pipcache ثم rm -rf /pipcache بنفس الخطوة RUN لذلك لن ينتهي به الأمر في الصورة.

تطوير البرامج صعب وستحدث مثل هذه الأخطاء دائمًا. بالتأكيد لا ينبغي لأحد أن يلوم المشرفين أو المساهمين على pip لهذا الحادث.

ومع ذلك ، أود أن أقترح أن هذا الخطأ يستحق نوعًا من تحليل ما بعد الوفاة من جانب فريق النقطة ، نظرًا لعدد الفرص (الضائعة) لهذا الخطأ الذي تم اكتشافه قبل الانزلاق إلى إصدار عام. فمثلا:

• الاختبار الآلي للوظائف الأساسية مثل --no-cache-dir
• فحوصات الالتزام المسبق أو الدمج المسبق أو الإصدار المسبق التي تحدد (أو تمنع) TODO s
• مراجعة (بشرية) للدمج مسبقًا لجميع تعليقات المراجعة التي لم يتم حلها في العلاقات العامة (يقوم Github تلقائيًا بجعل معظم سلاسل تعليقات المراجعة عند تغيير الكود المرتبط بها ، ويسمح لك مؤخرًا بوضع علامة يدويًا على سلاسل تعليقات المراجعة على أنها تم حلها)
• التغييرات في عملية الإصدار - لماذا لا تقوم بإصدار بيتا أولاً ثم الانتظار عدة أسابيع قبل الإصدار العام؟
• إلخ

قد يؤدي تشريح الجثة إلى عدد من التحسينات المفيدة للتأكد من أن البرنامج الأساسي لمشروع Python مثل pip لا يشحن بأخطاء بهذا الحجم في المستقبل.

يمكنني تكرار هذا الخطأ. تؤدي إزالة --no-cache-dir إلى إصلاحه. نظرًا لأنني لا أريدها في صورة عامل الإرساء ، فأنا أستخدم الحل

يبدو هذا كنسخة مكررة من المشكلة رقم 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 كإصلاح خطأ لهذه المشكلة. هل يمكن للأشخاص من هذا الموضوع تجربة العلاقات العامة والتحقق من أنها تعمل بالفعل على حل هذه المشكلة؟

ملاحظة: شكرًا 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

يجب على الأشخاص حقًا تثبيت Pip في CI كما تفعل مع أي حزمة أو تبعية أخرى ، IMO. خلاف ذلك ، ليس لديك إمكانية التكاثر وخطر الانكسار المفاجئ. من خلال التثبيت ، يمكنك التحقق من الأشياء مسبقًا والترقية وفقًا لسرعتك الخاصة.

يجب على الأشخاص حقًا تثبيت Pip في CI كما تفعل مع أي حزمة أو تبعية أخرى ، IMO. خلاف ذلك ، ليس لديك إمكانية التكاثر وخطر الانكسار المفاجئ. من خلال التثبيت ، يمكنك التحقق من الأشياء مسبقًا والترقية وفقًا لسرعتك الخاصة.

cjerdonek : أتفق معك في ذلك - من منظور المستخدم pip - إنها فكرة جيدة أن تثبت pip في العديد من السياقات (ربما معظمها). على أقل تقدير، إذا كنت لا يعلقون يجب أن نعرف أن كنت المخاطرة بالضبط هذا النوع من الشيء، وأنت لا يمكن أن يشكو إلى pip مشرفون اذا حدث ذلك!

ولكن ... من pip منظور معيل (وعلى نطاق أوسع من وجهة نظر فريق أساسي PyPA أو بايثون) وأعتقد أنه سيكون من الحكمة لعرض حقيقة أن عددا كبيرا من الناس لا يعلقون pip كأصل. إنه غير ملموس ، لكنه يظهر ثقة كبيرة من قبل قاعدة المستخدمين. (على سبيل المثال ، ربما بشكل غير متوقع ، من واقع خبرتي ، غالبًا ما تكون الحالة أن معظم الأدوات الأساسية غير مثبتة مثل معظم التبعيات. على سبيل المثال ، حيث أعمل ، عادةً ما يتم تثبيت Python بشكل فعال في إصدار ثانوي - تحصل إصدارات التصحيح الجديدة تلقائيًا تم الحصول عليها من خلال الإصدارات الجديدة. وأعتقد أن هذا يُظهر المستوى المرتفع من ثقة المستخدمين في هذه الأدوات الأساسية وإدارتها.)

حوادث كهذه تقوض تلك الثقة. لا تعد إنشاءات CI المعطلة هي المشكلة الفعلية (كما قلت ، يجب عليك إما تثبيت 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 .
بهذه الطريقة ، يمكنني فرض إعادة تنزيله وإعادة بنائه قبل التثبيت ، مع التأكد من مراعاة أي تغييرات يتم إجراؤها على توزيع MPI الخاص بي.

نفس المشكلة هنا ، قادرة على إعادة إنتاجها خارج نظام 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 / issues / 6163 # issuecomment -456772043

بصفتي مشرفًا للصيانة ، أود أن أقول إن إحدى المشكلات التي أواجهها هي معرفة ما يعتبره الناس وظيفة "رئيسية". شخصياً ، كنت سأفترض أن - no-cache-dir كان مكانًا مناسبًا إلى حد ما ، لذلك من الواضح أن حدسي ليس موثوقًا به في هذه الحالة :-) ، وبالتالي فإن ردود الفعل مثل هذه ذات قيمة خاصة.

FWIW: أستخدم --no-cache-dir كثير من الأحيان عند إنشاء صور Docker ، لمنع فرص ترك أي خداع في ذاكرة التخزين المؤقت في بيئة لن تكون مفيدة فيها.

يجب على الأشخاص حقًا تثبيت Pip في CI كما تفعل مع أي حزمة أو تبعية أخرى ، IMO. خلاف ذلك ، ليس لديك إمكانية التكاثر وخطر الانكسار المفاجئ. من خلال التثبيت ، يمكنك التحقق من الأشياء مسبقًا والترقية وفقًا لسرعتك الخاصة.

في العديد من البيئات ، لا تعتبر النقطة تبعية. يتم تثبيته عند إنشاء ملف Virtualenv.

وبالمناسبة ، لا يتم الاختبار هناك لمعرفة ما إذا كان منتجك يعمل مع أحدث الإصدارات. يؤدي تثبيت كل شيء فقط إلى استخدام الإصدارات القديمة. وسيصبح التحديث قريبًا مهمة لا يجرؤ أحد على البدء فيها. ذهبت هناك وقمت بذلك. لذا فإن رأيي هو التثبيت فقط إذا لزم الأمر حقًا. وحاول حل المشكلة بمجرد حدوثها.

نقطة 19.0.1 خارجة مع إصلاح هذه المشكلة.

لقد كنت متحمسًا لرؤية إصلاح الإصدار 19.0.1 الجديد ، ولكن ما زلت أواجه مشكلة. أقوم أيضًا بإنشاء صورة Docker بـ --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 الجديد ، ولكن ما زلت أواجه مشكلة. أقوم أيضًا بإنشاء صورة Docker بـ --no-cache-dir والتي تعمل بشكل جيد مع نقطة <19.0. أي شخص آخر يحصل على هذا؟

الإصلاح يعمل معي مع 19.0.1 - أظن أن لديك ذاكرة تخزين مؤقت لطبقة عامل إرساء تربكك؟ - جرب pip --version للتحقق من الإصدار الذي تستخدمه

لدي إصدار Python و Pip يتحقق من جميع ملفات Docker الخاصة بي ، ويبلغ 19.0.1 بشكل صحيح.

dmulter لقد في Gist من نقطة الصفر هذا الصباح وتعمل الأمور بشكل جيد هناك مع v19.0.1 . هل يمكنك مشاركة ملف Dockerfile الخاص بك في Gist أيضًا حتى نتمكن جميعًا من النظر إليه؟

فقط نظف كل شيء مرة أخرى فقط للتأكد. هذا هو Dockerfile وإخراج البناء الخاص بي.

راجع ملاحظتي حول إخراج الإنشاء لأوامر عامل الإرساء التي تم استخدامها.

هل يوجد حل لـ 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 ... ¯_ (ツ) _ / ¯

مثل @ 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 إصلاح المشكلة بالنسبة لي. آمل أن يساعد ذلك في تضييق الأمور.

نقطة 19.0.1 تعمل لدي في Virtualenv. لكن داخل Jenkins (Shining Panda) ما زال يفشل. تؤدي إضافة - no-use-pep517 إلى إصلاح المشكلة

أنا أعيد فتح الباب لأن بعض الأشخاص ما زالوا يواجهون نفس المشكلة.

يمكنني أيضًا أن أؤكد أن --no-use-pep517 أصلح المشكلة لي بعد الترقية إلى النقطة 19.0.1 لم يفعل ذلك.

ولكن لماذا يجب أن تتكيف كل هذه المشاريع عندما تحصل النقطة على نسخة جديدة؟

بناءً على طلب pradyunsg ، فتحت AssertionError في الإصدار 19.0.1 ، لأنه أضيق في النطاق وسيحتاج إلى تحقيق جديد. لذا فأنا أقوم بإعادة إغلاق هذه المشكلة.

ركض في نفس المشكلة. انتهى الأمر بتثبيت إصدار النقطة كإصلاح في الوقت الحالي.

pip install --upgrade pip==18.1

أو يمكن أن يتغير FROM python:3.6-alpine إلى FROM python:3.6.7-alpine

تم قفل سلسلة الرسائل هذه تلقائيًا نظرًا لعدم وجود أي نشاط حديث بعد إغلاقه. الرجاء فتح قضية جديدة للأخطاء ذات الصلة.