هذا هو الناتج من النقطة 3:

werner in ~ at octopus23
➜ pip3 install pipenv
Collecting pipenv
  Using cached https://files.pythonhosted.org/packages/2c/01/37a5867a47d52856b077d0faa561b791cb6e6e3e9410837b6d62f569c1e6/pipenv-11.10.1-py3-none-any.whl
Collecting virtualenv (from pipenv)
  Using cached https://files.pythonhosted.org/packages/ed/ea/e20b5cbebf45d3096e8138ab74eda139595d827677f38e9dd543e6015bdf/virtualenv-15.2.0-py2.py3-none-any.whl
Collecting pip>=9.0.1 (from pipenv)
  Using cached https://files.pythonhosted.org/packages/0f/74/ecd13431bcc456ed390b44c8a6e917c1820365cbebcb6a8974d1cd045ab4/pip-10.0.1-py2.py3-none-any.whl
Collecting setuptools>=36.2.1 (from pipenv)
  Using cached https://files.pythonhosted.org/packages/8c/10/79282747f9169f21c053c562a0baa21815a8c7879be97abd930dbcf862e8/setuptools-39.1.0-py2.py3-none-any.whl
Collecting virtualenv-clone>=0.2.5 (from pipenv)
  Using cached https://files.pythonhosted.org/packages/6d/c2/dccb5ccf599e0c5d1eea6acbd058af7a71384f9740179db67a9182a24798/virtualenv_clone-0.3.0-py2.py3-none-any.whl
Collecting certifi (from pipenv)
  Using cached https://files.pythonhosted.org/packages/7c/e6/92ad559b7192d846975fc916b65f667c7b8c3a32bea7372340bfe9a15fa5/certifi-2018.4.16-py2.py3-none-any.whl
Installing collected packages: virtualenv, pip, setuptools, virtualenv-clone, certifi, pipenv
Successfully installed certifi-2018.4.16 pip-10.0.1 pipenv-11.10.1 setuptools-39.1.0 virtualenv-15.2.0 virtualenv-clone-0.3.0

أعتقد أن هذا من المحتمل أن يكون نتيجة لاعتماد Pipenv على النقطة ، لكنني لست متأكدًا مما إذا كان يجب أن يكون Pipenv مسؤولاً عن ذلك. ربما يجب على Debian لأنهم هم من كسروا اقتران Python-pip. من المؤكد أن Pipenv ليست الحزمة الوحيدة المتوفرة اعتمادًا على النقطة أيضًا ، لكنني لست متأكدًا من أفضل الممارسات هنا.

ncoghlan هل يمكنك تقديم بعض الأفكار حول هذا الموضوع؟ خاصة

1. هل يجب أن تعتمد الحزمة على النقطة؟
2. إذا كانت الإجابة بنعم 1. هل يجب أن تكون مسؤولة عن هذا النوع من التعارض مع مدير حزم النظام؟
3. إذا كانت 2. هي الإجابة بنعم ، فكيف؟
4. إذا كانت 2. لا ، فمن يجب أن يكون المسؤول؟ هل ينبغي توجيه المستخدم لاستخدام حل بديل بدلاً من ذلك؟

على أي حال ، ربما لا يجب عليك sudo pip install أي شيء على Ubuntu على أي حال. يجب عليك القيام بأحد ما يلي بدلاً من ذلك

• استخدم APT على طول الطريق
• pip install --user
• مدير مخصص مثل pipsi

أو أفضل من ذلك ، تجنب نظام Python تمامًا ، واستخدم Pyenv أو غيره من مديري وقت تشغيل Python بدلاً من ذلك.

خدش هؤلاء. تجنب Python من APT ، نقطة.

ربما لا يجب أبدًا أن تقوم sudo pip بتثبيت أي شيء على Ubuntu على أي حال

في الواقع لم أفعل ذلك قط. أنا على دراية بمشاكل استخدام sudo pip ضمن Ubuntu ، لذلك أستخدم apt كلما أمكن ذلك أو ألتزم بـ --user .

آه أرى المشكلة الآن. وحدات المستخدم لها الأسبقية على وحدات النظام ، لكن /usr/bin يكون قبل $HOME/.local/bin بداخلك PATH . يحاول /usr/bin/python استيراد تثبيت نقطة النظام (والذي لا يزال 9.x) ، ولكن انتهى به الأمر بالعثور على تثبيت المستخدم (وهو 10.x). ما هذه الفوضى.

2095 هو نفسه ، لكنني أريد أن أبقي هذا مفتوحًا لأنني أعتقد أنه يجب أن يكون هناك حل أكثر قوة من الاعتماد على المستخدم الذي لديه PATH .

إنه مستقر جدًا عندما يكون لدى المستخدم:

• ˜/.local/bin في بداية المستخدم PATH . يجب أن يكون الإعداد الافتراضي على Ubuntu ، منذ 16.10 . إنها ممارسة جيدة لأنها تتيح سلوك pip install --user وهو حالة استخدام صالحة تمامًا
• يجب على المستخدم دائمًا استخدام pip install --user . العبث بنقطة النظام أمر سيء حقًا في كل توزيع ، حتى مجلدات "حزم التوزيع / حزم الموقع" الغريبة في دبيان لا تحمي من أخطاء المستخدم.

لقد تأكدنا من هذا السلوك في جميع عمليات تثبيت مستخدم ubuntu الخاصة بنا (تنظيم أكثر من 1000 تثبيت لإصدارات مختلفة من ubuntu) ، وكان الانتقال إلى pip10 بمثابة سحر.

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

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

ما تم إصلاحه بالنسبة لي هو الإضافة

export PATH="${HOME}/.local/bin:$PATH"

إلى الملف الشخصي.

تحرير: تأكد من تشغيل hash -r أو أدخل غلافًا جديدًا حتى يسري هذا التغيير.

لا أعتقد أن هناك الكثير الذي يمكننا القيام به للتعامل مع هذه المشكلة بشكل مستقل

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

slhck إنه أمر محبط حقًا أنه كان هناك xkcd هذا على وجه التحديد حول بيئات

إليك دليل لطيف خطوة بخطوة استخدمته بنجاح على Ubuntu 18.04:
https://phoikoi.io/2018/04/03/bootstrap-pipenv-debian.html

هناك أيضًا https://github.com/pypa/python-packaging-user-guide/issues/396 ، والذي يناقش مسألة ما إذا كنا قادرين على الخروج بقائمة التحقق أو البرنامج النصي لتحرّي الخلل وإصلاحه لمساعدة الأشخاص على تحديد و حل المشكلات المحتملة في بيئتهم. سأقوم بتدوين ملاحظة هناك حول احتمالية حدوث تعارض في الطلبات PATH / sys.path .

شكرا ، slhck . لقد وفر لي عمل التصدير معظم الوقت ؛ لقد أضفته إلى / etc / profile.

إنه لأمر غبي حقًا أن لدينا مستويين من حزم البرامج على Linux. والأسوأ من ذلك ، مع الإصدار الأخير من * buntus ، تم كسر كلتا نكهات أحدهما (نقطة / نقطة 3).

لقد كتبته على Launchpad: https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1772746

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

كنت أواجه نفس المشكلة في Ubuntu 18 و Python 3.6

فيما يلي الخطوات التي اتبعتها:

1) أولاً كنت أتلقى الخطأ:

Traceback (آخر مكالمة أخيرة):
ملف "/ usr / bin / pip" ، السطر 9 ، في
من استيراد النقطة الرئيسية
خطأ في الاستيراد: لا يمكن استيراد الاسم الرئيسي

2) قمت بتعديل ملف / مستخدم / بن / نقطة إلى:

استيراد النظم
من pip._internal import main كـ _main
إذا كان __name__ == '__main__':
sys.exit (main ())

3) ثم بدأت تعطيني هذا الخطأ:

Traceback (آخر مكالمة أخيرة):
ملف "/ usr / bin / pip3" ، السطر 11 ، في
sys.exit (main ())
NameError: لم يتم تعريف الاسم "main"

4) قمت بتعديل / usr / bin / pip3 إلى:

استيراد النظم
من pip._internal import main كـ _main
إذا كان __name__ == '__main__':
sys.exit (_main ())

5) ثم بدأت في الحصول على الخطأ:

Traceback (آخر مكالمة أخيرة):
ملف "/ usr / bin / pip3" ، السطر 11 ، في
sys.exit (main ())
NameError: لم يتم تعريف الاسم "main"

6) أعدت تسمية main () إلى _main () ، و voila .. لقد نجحت !!! :) :)

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

تحرير: حل حل slhck . تحتاج إلى أن يكون لديك ~/.local/bin في مسارك

الحصول على نفس المشكلة على أوبونتو 16.04.

$ sudo apt install python3-pip
$ pip3 --version
pip 8.1.1 from /usr/lib/python3/dist-packages (python 3.5)
$ python3 -m pip install --user pipenv
$ pip3 --version
Traceback (most recent call last):
  File "/usr/bin/pip3", line 9, in <module>
    from pip import main
ImportError: cannot import name 'main'

# revert back and fix pip
$ sudo python3 -m pip uninstall pip && sudo apt install python3-pip --reinstall

أريد فقط أن أضيف أنني عثرت على هذه المشكلة أيضًا. كان لدي بالفعل ~ / .local / bin كأول شيء في طريقي. المشكلة هي كيف يقوم bash بتجزئة الأوامر. تم العثور على حل هذه المشكلة هنا: https://github.com/pypa/pip/issues/5221#issuecomment -381568428

thernstig نعم ، هذا صحيح - لقد أضفت الأمر hash -r الضروري إلى الحل أعلاه ، والذي نسيت أن أذكره صراحة.

slhck لا مشكلة ، سعيد لأنني استطعت المساعدة

أدركت أن المشكلة مغلقة ، لكنني أنشرها على أمل أن يساعد ذلك في تجنب التعديلات على PATH. ركضت إلى هذا اليوم عند إعداد جهاز Ubuntu 18.04 جديد وتمكنت من حله بدون تعديلات PATH ، على الرغم من أنني قمت بإعادة التشغيل (أنا متأكد تمامًا من أن تسجيل الخروج / الدخول سيعمل ، لكن لم يتم التحقق).

بعد تثبيت pip3 عبر python3-pip و pipenv بـ pip3 install --user pipenv تلقيت خطأ الموضوع. كنت على وشك استخدام الحل البديل من slhck عندما لاحظت ما يلي في ~/.profile (مخزون ، ليس لدي أي تعديلات):

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi

من الغريب ، لقد أعيد تشغيل الكمبيوتر وبالتأكيد ، تم حل المشكلة نظرًا لأن .local/bin كان الآن في بداية PATH وعملت pip3 مرة أخرى.

jlitzingerdev ، أنا متأكد تمامًا من أن المسار هو الافتراضي ، إنه فقط بالنسبة أستخدم غلافًا وملفًا شخصيًا مختلفين ، فقد قمت بإزالته أو إنشائه من نقطة الصفر ، ومن ثم فإن "الحل البديل" الخاص بي لم يكن ضروريًا في المقام الأول. سعيد لأنك حصلت عليه أحسب.

slhck إنه كذلك ، لكنه قد لا يكون في PATH عند تسجيل الدخول الأول لأن ~/.local/bin قد لا يكون موجودًا ، أو كانت هذه هي حالتي الخاصة.

ماذا علينا أن نفعل؟

أريد فقط أن أقول شكراً لك لتضمين أوامر الاستعادة ، لقد كنت أواجه مشكلة في جعل Pip يعمل مرة أخرى.

أريد تثبيت pipenv تحت Ubuntu 18.04. عندما أفعل ذلك ، فإنه يكسر النقطة / النقطة 3.

نتيجة متوقعة

نسخة مثبتة وعاملة من pipenv.

نتيجة فعلية

pip / pip3 مكسورة ، اعتمادًا على ما إذا كنت أرغب في تثبيت pipenv من خلال pip أو pip3.

➜ pip
Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main

خطوات التكرار

1. Set up Ubuntu 18.04

2. Run `pip install pipenv` or `pip3 install pipenv`

3. Run `pip` or `pip3` – the error is printed, and pip / pip3 do not work anymore.

لإصلاح المشكلة ، لا بد لي من تشغيل:

sudo python -m pip uninstall pip && sudo apt install python-pip --reinstall
sudo python3 -m pip uninstall pip && sudo apt install python3-pip --reinstall

لكن لا يمكنني تثبيت pipenv باستخدام pip. التثبيت من خلال apt لا يعمل بسبب عدم توفر

لدي 3 نقاط في ubuntu 18 نقطة و pip3 و pip3.6 هي 2.7 نقطة 3 هي 3.5 و pip3.6 لـ 3.6 الآن والتي تُظهر النقطة موقع الملف في .local / bin. قمت بإزالة ملف pip و pip3 من هنا. الآن الذي يظهر لي pip3 / usr / bin / pip3. قم بتشغيل الأمر sudo nano / usr / bin / pip3 لتغيير السطر الأول للمترجم مثل! # / usr / bin / python3 إلى # / usr / bin / python3.5. يعمل لدي. كل ما عندي من عمل بالنقاط. آمل أن يساعد هذا

لدي 3 نقاط في ubuntu 18 نقطة و pip3 و pip3.6 هي 2.7 نقطة 3 هي 3.5 و pip3.6 لـ 3.6 الآن والتي تُظهر النقطة موقع الملف في .local / bin. قمت بإزالة ملف pip و pip3 من هنا. الآن الذي يظهر لي pip3 / usr / bin / pip3. قم بتشغيل الأمر sudo nano / usr / bin / pip3 لتغيير السطر الأول للمترجم مثل! # / usr / bin / python3 إلى # / usr / bin / python3.5. يعمل لدي. كل ما عندي من عمل بالنقاط. آمل أن يساعد هذا

لا يتم تشجيع كل هذه الخطوات في الواقع. لا يجب عليك تحرير الملفات يدويًا في /usr/bin . بدلاً من ذلك ، حاول إلغاء تثبيت pip كما هو مذكور أعلاه ، وإعادة التثبيت عبر apt . هذا يجب أن تحصل على تثبيتات النظام الصحيحة. إذا كانت لديك مشاكل مع pipenv ، فالرجاء فتح مشكلة جديدة ووصف مشكلتك بدلاً من محاولة مثل هذه الحلول.

إعادة التثبيت عبر apt كما هو مذكور أعلاه لن يغير أي شيء لأنه يولد نفس الإخراج. إنها حالات بسيطة لا يمكنها استيراد name main وعند القيام بنقطة الاستيراد في مترجم Python ، فإنها تقوم باستيرادها كوحدة نمطية ، مما يعني أن الاسم main غير متاح في الوحدة التي تحاول البحث فيها. الآن لم أقترح التعديل أعلاه بشكل أعمى. بصفتي متحمسًا للبرامج عندما كنت في ubuntu14 ، قمت بفحص ملف Pip وله نفس الرمز الموجود في ubuntu18 pip3. فما الذي تغير. نسخة الثعبان التي تأتي معدة مسبقًا.

لأن النقطة لـ python3.5 و 2.7 لها تعريف رئيسي فقط في وحدة النقطة.
وقد حددت python3.6 في pip._internal

الآن البيانين أعلاه يحل مشكلة الجميع

المشكلة تكمن في استخدام المترجم نفسه

بيثون 3. ولكن إلى أي نوع من أنواع الثعبان تشير إليه
المطورون الذين لم يكن لديهم سوى الإصدار 2.7 من python وتغييرهم إلى ubuntu18 من المحتمل أن يكون لديهم Python 3 مثل python3.6

ولكن ماذا عن أولئك الذين قاموا بتثبيت python3.4 pr 3.5. أولاً ، يشير python3 إلى python3.5 والآن بعد الترقية سيشير إلى ppython3.6

لذا الطريقة التي تم التعامل بها من قبل دبيان تسببت في كسرها

مجرد ذكر المترجم الصحيح سيحل المشكلة
كلاهما به أخطاء

من استيراد النقطة الرئيسية
و
من pip._internal import main كـ _main

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

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

آمل في هذه المرحلة أن تحصل عليها. سلام ولا تزعجني مرة أخرى

@ r-tron18 أشعر بالأسف لأنك تلقيت محاضرة على ما كان يعنيه اقتراح بناء - ألا تضطر إلى تعديل ملف نظام. من السياق الصغير الذي كنت تقدمه في منشورك الأصلي ، كان من المستحيل معرفة ما إذا كنت مستخدمًا متمرسًا يعرف ما يفعله ، أو مجرد تطبيق الحلول البديلة التي ربما تكون قد وجدت في مكان آخر. أقضي الكثير من الوقت على مختلف استكشاف الأخطاء وإصلاحها وQ & A المواقع، وأعتقد كنت توافق على أن لا ينبغي لنا أن تشجيع المستخدمين على تجربة الإصلاحات العشوائية أو sudo -edit ملف شحنها النظام، الذي غالبا ما يؤدي إلى المزيد الأخطاء والارتباك. هذا هو أكثر من قضية عامة.

ما زلت غير مقتنع بأن ما تقترحه هو حل موثوق. و: يمكننا إجراء مناقشة مدنية حول مزايا هذا الحل - GitHub هو مكان يسمح لي بالتعبير عن ذلك.

السبب هو: تغيير رمز shebang من /usr/bin/pip3 إلى #!/usr/bin/python3.5 لن يؤدي إلا إلى إبقائك عالقًا في هذا الإصدار. يجب أن تقرأ #!/usr/bin/python3 ، ويجب أن يكون هذا رابطًا رمزيًا لـ /usr/bin/python3.6 (أو أي شيء موجود حاليًا على نظامك). من المحتمل أن تؤدي أي ترقية لـ Python إلى تغيير هذا الملف على أي حال.

قول انت:

ولكن ماذا عن أولئك الذين قاموا بتثبيت python3.4 pr 3.5. أولاً ، يشير python3 إلى python3.5 والآن بعد الترقية سيشير إلى ppython3.6
لذا الطريقة التي تم التعامل بها من قبل دبيان تسببت في كسرها

هل تقول أنه بعد ترقية Python 3.5 إلى Python 3.6 ، لم يتم تحديث هذا الرابط الرمزي python3 ؟ إذا كان ما تراقبه هو بالفعل خطأ في Debian أو Ubuntu ، حيث فشلت ترقية Python في تعيين الروابط الرمزية الصحيحة ، فمن المحتمل أن تتم معالجة هذا الخطأ في البداية ، أليس كذلك؟

أدركت أن المشكلة مغلقة ، لكنني أنشرها على أمل أن يساعد ذلك في تجنب التعديلات على PATH. ركضت إلى هذا اليوم عند إعداد جهاز Ubuntu 18.04 جديد وتمكنت من حله بدون تعديلات PATH ، على الرغم من أنني قمت بإعادة التشغيل (أنا متأكد تمامًا من أن تسجيل الخروج / الدخول سيعمل ، لكن لم يتم التحقق).

بعد تثبيت pip3 عبر python3-pip و pipenv بـ pip3 install --user pipenv تلقيت خطأ الموضوع. كنت على وشك استخدام الحل البديل من slhck عندما لاحظت ما يلي في ~/.profile (مخزون ، ليس لدي أي تعديلات):

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi

من الغريب ، لقد أعيد تشغيل الكمبيوتر وبالتأكيد ، تم حل المشكلة نظرًا لأن .local/bin كان الآن في بداية PATH وعملت pip3 مرة أخرى.

إنه يعمل بالنسبة لي ، بعد إعادة تشغيل كل شيء يعمل بشكل جيد. (بعد التثبيت: "pip3 install --user pipenv" أعد تشغيل النظام وسيعمل.