هذه مشكلة دبيان

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

أقترح عليك الانتظار للحصول على نسخة معبأة مناسبة من النقطة 10 من دبيان - كما يقول RonnyPfannschmidt ، لا يجب أن تستخدم النقطة لترقية حزم النظام ...

يبدو أن نص Debian pip3 يستخدم العناصر الداخلية لـ pip ، لذا فإن الحصول على إصلاح متوافق مع pip10 أمر متروك لهم بالتأكيد (وأنا أتوقع تمامًا أن ينتظروا إصدار حزمة pip10 الخاصة بهم حتى يتم فرزهم).

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

اقنع الناس debian / ubuntu بعدم البائعين ثم اتركوا نصف حزمهم ، وستكون هذه حجة صحيحة.

يمكنك استخدام virtualenv أو venv لعزل نفسك عن تثبيت نظام Pip.

لا يجب أن تعدل الملفات المُدارة من قبل مدير الحزم (هنا تثبيت نقطة النظام) - أعتقد أنهم لا يتوقعون أن يقوم المستخدمون بتعديل الأشياء - من المحتمل أن لا يدعمها Debian. لا بد أن يسبب مشاكل مثل هذا.

نفس المشكلة على Fedora أيضًا.

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

@ اسم وهمي تم إصدار نسختين من الإصدارات المسبقة:

• 10.0.0b1 في 31 مارس
• 10.0.0b2 في الثاني من أبريل

@ Fake-name بالإضافة إلى ذلك ، فإن الاقتراح العام للاستخدام في جميع التوزيعات هو - استخدام virtualenv ، لا تخرب النظام ، وهذا يعمل - يقوم الأشخاص فقط باتباع الخط ثم يتساءلون متى تنكسر الأشياء ويلومون النقطة

كان هناك الكثير من الاختبارات اليدوية والآلية باستخدام virtualenvs التي تعمل

أيضًا في Virtualenv على الأقل يجب ألا يكون هناك أمر pip3 الذي تم إنشاؤه باستخدام Debian - لذا ما الذي تتحدث عنه بخصوص هذا الاختراق في virtualenvs - يرجى تقديم بيانات كافية للتحقق فعليًا بدلاً من التذمر من الأعطال دون تقديم البيانات اللازمة للتحقق منها

شركة pip مدفوعة من قبل المتطوعين ، وليست شركة بها عشرات الموظفين

~ محذوف ~. كان يخلط بين هذا و https://github.com/pypa/pip/issues/5220

أنا ديرب.

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

@ Fake-name شكرًا للمتابعة - من الشائع بشكل مدهش عدم تطابق مشكلة التفاصيل عندما يكون لإصدار رئيسي تأثير متعدد الأوجه وجزء منه يحاول إفساد يومك

سيكون تجربة مستخدم جيدة إذا لم تتأثر النقطة بالترقية في هذه الحالة

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

تفضل دائمًا "python3 -m pip" على pip3 "أو حتى أفضل" / usr / bin / env python3 -m pip "فهي أكثر أمانًا وتسمح بتجنب هذه المشكلة مع pip10

لقد حللنا هذه المشكلة عن طريق مسح التجزئة في باش:

$ hash -d pip

أو في اندفاعة (ش):

$ hash -r pip

تعرضت هذه المشكلة أيضًا أثناء إنشاء صور عامل الإرساء.

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

_ أنت تستخدم إصدار النقطة 8.1.1 ، ولكن الإصدار 10.0.0 متاح.
يجب أن تفكر في الترقية عبر الأمر "pip install --upgrade pip".

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

qacollective - أعتقد أن الحجة هنا هي أن

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

أنا شخصياً ، على الأقل بالنسبة للبيثون على أوبونتو ، أتمنى لو تركوها. يتراوح إصدار كل حزمة من حزم python الموجودة في apt من قديم حقًا إلى متحجر. Apt غير مجدية أساسًا للبيثون ، IMHO.

FWIW ، أميل إلى العثور على أفضل خيار هو عدم تثبيت نقطة التوزيع مطلقًا في المقام الأول ، ولكن بدلاً من ذلك قم بتثبيتها يدويًا عبر get-pip.py . بهذه الطريقة ، ليس لديك مشاكل مع مدير حزم النظام الأساسي الذي يعرف فقط بعض حزم python.

استخدم دائمًا --user لتجنب قتل نظامك

/usr/bin/env python3 -m pip intall --user --upgrade pip

يجب أن يتعامل مع معظم صندوق عربات التي تجرها الدواب وينتج عن ذلك تثبيت الإصدار الصحيح من النقطة في ˜/.local/bin .

يمكنني أن أؤكد أن حل standag يعمل.

القليل من الخلفية: بعد الترقية (تثبيت نقطة - U نقطة) على فانيلا أوبونتو 16.04 (AWS AMI) يصل المرء إلى الموقف التالي:
$ PATH = ..: / usr / local / bin: ... : / usr / bin: ...
/ usr / bin / pip لا يزال هو الإصدار القديم / "oem" (معطل)
/ usr / local / bin / pip هو البرنامج النصي الجديد v10 (يعمل بشكل جيد عند الاستدعاء مباشرة)

على الرغم من أن نسخة النقطة المناسبة تسبق النسخة المكسورة في المسار ، لا يزال bash يتذكر النسخة القديمة ، لذلك عندما تستدعيها كـ "pip" ، ستحصل على النسخة القديمة المكسورة قيد التشغيل. Hash-d pip أو hash -r يحل المشكلة.

أولاً ، بعض الملاحظات حول ما حدث هنا على Debian / Ubuntu (ومن المحتمل أن يكون هناك عدد قليل من توزيعات Linux الأخرى):

• لا تدعم النقطة استخدام عناصرها الداخلية عن طريق استيرادها. المزيد عن ذلك في الوثائق هنا .
• لا يدعم Debian (ومن ثم Ubuntu) تعديل الملفات التي يديرها مدير الحزم باستخدام شيء ما ، ليس مدير الحزم الخاص بهم.

هذه المشكلة ناتجة ، حسنًا ، عن انتهاكهما بطريقة ما.

• تستخدم دبيان الطرق الداخلية للنقطة (والتي لم تعد تعمل بسبب إعادة تنظيم الأجزاء الداخلية للنقطة). تفترض دبيان هنا أن نسخة النقطة في مستودعاتها هي النسخة التي سيتم تثبيتها.
• يؤدي تشغيل pip install --upgrade pip كجذر بدون أي معلمات أخرى إلى تعديل الملفات التي من المفترض أن تديرها apt ، والتي تكسر البرنامج النصي بواسطة Debian.

بعض النصائح العامة حول Linux:

• إنها عادة جيدة أن تستخدم --user عندما تكون خارج venv.

  pip install --upgrade --user pip
  

• لا تقم أبدًا بتشغيل pip مع sudo إلا إذا كنت تعرف ما تفعله.

ما الحل؟

يكون حل standag مفيدًا عندما يكون السبب في ذلك هو التخزين المؤقت

hash -r pip # or hash -d pip

إذا قمت بتعديل تثبيت مدير حزمة نظام التشغيل الخاص بك للنقطة (على سبيل المثال باستخدام sudo pip ) ولا يزال python -m pip يعمل ، فإن أحد الحلول هو إلغاء تثبيت الإصدار المثبت من نقطة وإعادة تثبيت الإصدار المثبت من مدير الحزم .

python -m pip uninstall pip  # this might need sudo
sudo apt install --reinstall python-pip

إذا لم تكن تستخدم Debian / Ubuntu _ و_ تعطلت النقطة ، فحاول تشغيل:

python -m pip install --force-reinstall pip

إذا لم يؤدِ ذلك إلى حل مشاكلك ، فيرجى تقديم مشكلة جديدة.

[تم التعديل بواسطة pradyunsg :

ماذا عن حلها خارج عامل الميناء؟ إنه معطل في نظامي العادي ولم يتعرف أمر التجزئة على النقطة.
thinkdigital@thinkdigital-HP-Spectre-x360-Convertible:~$ hash -d pip bash: hash: pip: not found

لقد عثرت على pip3 ، الإصدار 9.0.1 مثبتًا في Virtualenv من مشروع وقمت بنسخه إلى / usr / bin وهو يعمل مرة أخرى. فيما يلي محتويات ملف pip3 القابل للتنفيذ لمن يرغبون في إصلاحه بأنفسهم أيضًا.

# -*- coding: utf-8 -*-
import re
import sys

from pip import main

if __name__ == '__main__':
    sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
    sys.exit(main())

أنا متأكد من أن كل ما عليك فعله هو حفظ ذلك في ملف يسمى pip3 ، وجعله قابلاً للتنفيذ عن طريق تشغيل sudo chmod + x ./pip3 ، وتشغيل sudo apt ، وإزالة python3-pip ، ثم نسخه إلى دليل bin عن طريق تشغيل sudo cp ./pip3 / usr / bin.
هذا هو الملف الخام لأولئك الذين يريدون فقط تنزيله ونقله.
pip3.zip

إنه يعمل بالنسبة لي:
حليقة https://bootstrap.pypa.io/get-pip.py | سودو بيثون

أنا آسف ، لكني أود أن أشير إلى أن تشغيل كود python curl'd من بعض مواقع الويب مع الوصول إلى الجذر هو مجرد أمر غير آمن بشكل مرعب.

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

في هذه الحالة ، لا يعمل الإصدار من مدير حزم النظام. حتى
بعد التطهير وإعادة التثبيت.

في الخميس ، 19 أبريل 2018 ، الساعة 1:53 صباحًا كتب Paul Moore [email protected] :

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

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/pypa/pip/issues/5221#issuecomment-382660881 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AV-Hfecz8l1NEyq3vsih0DpNP7QYdxuvks5tqFCdgaJpZM4TVEq6
.

إذا لم تنجح إعادة تثبيت حزمة النظام ، فتحقق مما إذا كان لديك pip10 في مكان ما في / usr / local / واحذف المجلد بأكمله.

عمل استبدال واحد من / usr / bin بالنسبة لي على الرغم من أنني أعتقد أن هذا
تلك التي كان مدير حزم النظام يقوم بتثبيتها.

[ pradyunsg قص محتوى البريد الإلكتروني]

ThinkDigitalRepair هل يساعد ما يلي؟

في حالات أخرى ، سترغب في تمرير --user عند تثبيت / ترقية الحزم. TBH ، على Linux ، من الجيد استخدام --user .

pip install --upgrade --user pip

موافق. شكرا. لقد أفسدت الأمر باتباع برنامج تعليمي لـ Jupyter Notebook من
الموقع الذي يخبرك بترقية النقطة مباشرة. النسخ واللصق بدون
معرفة العواقب مرة أخرى. :(

[ pradyunsg قص محتوى البريد الإلكتروني]

نأمل أن تعمل ThinkDigitalRepair ، النقطة 10 على تحسين الأمور - فهي تطبع رسائل خطأ أفضل بدلاً من PermissionError طويل عندما يحدث هذا.

إغلاق هذه المشكلة الآن لأنه لا يوجد شيء عملي هنا من نهاية النقطة.

أي شخص يبحث عن كيفية إصلاح / حل هذه المشكلة ، يرجى إلقاء نظرة على https://github.com/pypa/pip/issues/5221#issuecomment -382069604.

pradyunsg في كثير من الحالات ، لن تعمل الحلول الواردة في هذا التعليق. ضمن إصدار Ubuntu 17.10 جديد ، قم بتشغيل pip install --upgrade pip : بعد ذلك سيتم كسر الأمر pip ، ولن تعمل الحلول من التعليق على إصلاحه. ولا ينبغي لهم!

إن وجود نظام مثبت على نظام النقطة 9 مع تثبيت مستخدم نقطة 10 ، يجعل البرنامج النصي لنقطة النظام يحاول استيراد main () من نقطة المستخدم 10 ، باستخدام مسار استيراد غير صحيح. لن تصلح Hash -r أو -d ذلك لأن أمر pip سيستمر في تشغيل نقطة النظام افتراضيًا. ولن يصلح أي منهما ترقية نقطة المستخدم ، حيث ستظل نقطة النظام 9 ، وستظل نقطة المستخدم 10 ، وبالتالي سيستمر الاستيراد بالفشل.

يجب أن يكون الحل لهذه الحالات هو إلغاء تثبيت إحدى النقطتين.

• python -m pip uninstall pip --user ، مع الاحتفاظ بنقطة النظام الأقدم

أو

• sudo apt remove python-pip واحتفظ بنقطة تثبيت المستخدم ، والتي لن يمكن الوصول إليها عن طريق تشغيل pip في المحطة افتراضيًا. ستحتاج إما إلى تشغيله بـ python -m pip ، أو إضافة المسارات إلى PATH env var ، إلخ.

كل هذا ينطبق على كليهما ، النقطة تحت بيثون 2 و 3.

في جميع أنظمة Ubuntu الخاصة بي (16.04 ، 17.10.18.04) ، لديّ نقطة النظام للإصدار القديم والمستخدم مع النقطة 10 ولا أرى أبدًا خطأ الاستيراد الخاص بك.
هل أنت متأكد من أنه ليس لديك نقطة نظام تالفة؟

gsemet ربما أضفت ~/.local/bin إلى PATH env var (أو ربما تستخدم قشرة مختلفة أكثر ذكاءً من bash الافتراضي) ، لذلك عندما تقوم بتشغيل pip فإنه يستخدم برنامج النقطة 10 المثبت بواسطة المستخدم ، وليس البرنامج النصي Pip 9 المثبت. في Ubuntu ، هذا ليس هكذا افتراضيًا. يمكن القيام بذلك ، بالتأكيد ، وأتمنى أن يكون الأمر كذلك بشكل افتراضي. ولكن افتراضيًا ، سيقوم الأمر pip باستدعاء النقطة المثبتة في النظام ، حتى إذا كان لديك مستخدم مثبت.

كيفية إعادة إنتاج هذا في ظل تثبيت Ubuntu 17.10 جديد ، بما في ذلك الدليل على أن الأوامر الواردة في التعليق 5221 تفشل في إصلاحه ، وما اقترحته يعمل على إصلاحه.

تثبيت كل من النقاط (النظام والمستخدم) ، والذي يكسر أمر النقطة:

vfisa<strong i="7">@vilos</strong>:~$ sudo apt install python-pip
(...)

vfisa<strong i="8">@vilos</strong>:~$ pip --version
pip 9.0.1 from /usr/lib/python2.7/dist-packages (python 2.7)

vfisa<strong i="9">@vilos</strong>:~$ which pip
/usr/bin/pip

vfisa<strong i="10">@vilos</strong>:~$ pip install pip --upgrade --user
Collecting pip
  Downloading https://files.pythonhosted.org/packages/0f/74/ecd13431bcc456ed390b44c8a6e917c1820365cbebcb6a8974d1cd045ab4/pip-10.0.1-py2.py3-none-any.whl (1.3MB)
    100% |████████████████████████████████| 1.3MB 631kB/s 
Installing collected packages: pip
Successfully installed pip-10.0.1

vfisa<strong i="11">@vilos</strong>:~$ pip
Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main

vfisa<strong i="12">@vilos</strong>:~$ python -m pip --version
pip 10.0.1 from /home/vfisa/.local/lib/python2.7/site-packages/pip (python 2.7)

vfisa<strong i="13">@vilos</strong>:~$ which pip
/usr/bin/pip

كما ترى ، يشير الأمر pip إلى نقطة النظام افتراضيًا ، وليس المستخدم الذي قام بتثبيته.

أوامر من تعليق مرجعي ، دليل على عدم حلها للمشكلة:

vfisa<strong i="19">@vilos</strong>:~$ hash -r

vfisa<strong i="20">@vilos</strong>:~$ pip
Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main

vfisa<strong i="21">@vilos</strong>:~$ hash -d
hits    command
   1    /usr/bin/pip

vfisa<strong i="22">@vilos</strong>:~$ pip
Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main

vfisa<strong i="23">@vilos</strong>:~$ python -m pip install pip --force-reinstall --user
Collecting pip
  Using cached https://files.pythonhosted.org/packages/0f/74/ecd13431bcc456ed390b44c8a6e917c1820365cbebcb6a8974d1cd045ab4/pip-10.0.1-py2.py3-none-any.whl
Installing collected packages: pip
  Found existing installation: pip 10.0.1
    Uninstalling pip-10.0.1:
      Successfully uninstalled pip-10.0.1
Successfully installed pip-10.0.1

vfisa<strong i="24">@vilos</strong>:~$ pip
Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main

vfisa<strong i="25">@vilos</strong>:~$ which pip
/usr/bin/pip

كما ترى ، طالما تم تثبيت كلتا النقطتين وكان الأمر pip يشير إلى نقطة النظام (السلوك الافتراضي في Ubuntu) ، فستستمر المشكلة.

إصلاح الخيار 1:

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

vfisa<strong i="34">@vilos</strong>:~$ sudo apt remove python-pip
(...)

vfisa<strong i="35">@vilos</strong>:~$ pip
bash: /usr/bin/pip: No such file or directory

vfisa<strong i="36">@vilos</strong>:~$ python -m pip --version
pip 10.0.1 from /home/vfisa/.local/lib/python2.7/site-packages/pip (python 2.7)

يمكنك إضافة ~/.local/bin إلى PATH env var ، لتتمكن من استخدام الأمر pip مع نقطة المستخدم.

إصلاح الخيار 2:

قم بإزالة نقطة المستخدم ، واحتفظ بنقطة النظام ، وهي أقدم ولكن بشكل افتراضي لديها أمر عمل pip في المسار.

vfisa<strong i="45">@vilos</strong>:~$ python -m pip uninstall pip
Uninstalling pip-10.0.1:
  Would remove:
    /home/vfisa/.local/bin/pip
    /home/vfisa/.local/bin/pip2
    /home/vfisa/.local/bin/pip2.7
    /home/vfisa/.local/lib/python2.7/site-packages/pip-10.0.1.dist-info/*
    /home/vfisa/.local/lib/python2.7/site-packages/pip/*
Proceed (y/n)? y
  Successfully uninstalled pip-10.0.1
You are using pip version 9.0.1, however version 10.0.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

vfisa<strong i="46">@vilos</strong>:~$ pip --version
pip 9.0.1 from /usr/lib/python2.7/dist-packages (python 2.7)

fisadev بالتأكيد ، هذا ضروري لدعم حزمة تثبيت "pip --user" التي يمكن تثبيتها بواسطة المستخدم. ولكن أعتقد أنه يجب إخبار المستخدمين "إذا كنت تريد فرض التحديث على النقطة 10 قبل تحديث حزمة debian / ubuntu ، فأنت بحاجة إلى استخدام pip install --user --upgrade pip والتأكد من وجود $HOME/.local/bin في مسارك . من السهل القيام به.

gsemet أوافق ، يجب إخبار المستخدمين بمتطلبات المسار. لم يتم ذكر هذا في التعليق الذي تتم الإشارة إليه من سلاسل الرسائل الأخرى كحل ، وفي إحدى الحالات تم قفل المناقشة حتى بعد أن قال المستخدم إنه نفذ هذه الأوامر ولم يحل المشكلة: /

fisadev شكرا جزيلا. خيار الإصلاح 1 يساعد حقًا.

تضمين التغريدة

دائمًا ما يكون استبدال نقطة النظام باستخدام النقطة عملاً من أعمال التخريب المتعمد للنظام حيث يكون الشخص الذي يتسبب فيه هو المسؤول عن التداعيات

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

لحسن الحظ:
sudo python -m pip install pip==9.0.1
كان علاجًا سهلاً بدرجة كافية.

ومع ذلك ، فإن إلقاء اللوم على الضحية ليس إجابة.

مرحبًا @ rod-app!

إذا كان الأمر كذلك ، فلا ينبغي أن تزعج النقطة نفسها المستخدم للترقية من 9.0.1 إلى 10.0.1 مع تنفيذ كل أمر نقطة.

لقد لاحظنا ذلك وعملنا مع بائعي أنظمة التشغيل لتجنب ذلك في الإصدارات المستقبلية من Pip. - # 5346.

لمعالجة المشكلة جريت ...

sudo geany -i /usr/bin/pip

... وحرروا debian's provided / usr / bin / pip لاستبداله بـ ...

#!/bin/sh
# GENERATED BY CEFN
python -m pip "$@"

والمكافئ لـ / usr / bin / pip3 (لاحظ أن هذا يستدعي python3 بدلاً من ذلك).

#!/bin/sh
# GENERATED BY CEFN
python3 -m pip "$@"

... الذي يعيد الوظائف الكاملة للنقطة على الرغم من تثبيت الإصدار 10 في حزم الموقع الخاصة بي. أعتقد أن هذا سيستمر تمامًا طالما استغرق الأمر Debian لإصلاحه ، (أو إعادة كسره) عن طريق إرسال حزمة python-pip محدثة. لا أعرف لماذا لم يستخدموا الحزمة الرئيسية في المقام الأول.

النسخة الرسمية

إصدار النقطة المثبت في .local/bin/pip الموضح أدناه مربي بعض الشيء ، ويتضمن بعض الاستبدال لإزالة امتدادات -script و .py و .pyw و. exe من الوسائط التي تم تمريرها ، لكنني لا أعرف ماذا يفعل ذلك أو لماذا أحتاجه لذلك تركته على النحو الوارد أعلاه من أجل البساطة.

#!/usr/bin/python

# -*- coding: utf-8 -*-
import re
import sys

from pip._internal import main

if __name__ == '__main__':
    sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
    sys.exit(main())

لقد وجدت سببًا غير ذي صلة لمشكلة النقطة v10 هذه. عند ترقية النقطة باستخدام نقطة نظام قديمة جدًا (v1.5.6 على Debian Jessie ، على سبيل المثال ، قديم ثابت) والتي - يكون النظام هو الإعداد الافتراضي ، لاحظت أنه تم تثبيت نصوص غير صحيحة ، على سبيل المثال /usr/local/bin/pip تحتوي على from pip import main - الذي وجدته من خلال النظر في الملفات. أفترض أن هذا يرجع إلى أن النقطة القديمة (أو ربما حزم التثبيت التي تستخدمها) تقوم بتثبيت ملف .whl بشكل غير صحيح.

أصلح هذا python -m pip install --force-reinstall pip هذا.

يوفر 5599 معلومات ويوفر موقعًا واحدًا لطلب المساعدة لحل هذه المشكلة للمستخدمين النهائيين.

قسم التعليقات الخاص بهذه المشكلة مفتوح للمستخدمين لمناقشة مشاكل وحلول محددة. :)