Pip: افتراضي إلى --user

ماذا يعني هذا بالنسبة لتعليمات تثبيت pypa؟

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

بغض النظر عن التغيير --user ، يجب أن توضح التعليمات الحالية أن بعض التوزيعات مثل debian ، تعطل ensurepip ، لذلك لا ينبغي عليهم البحث عنها كطريقة للحصول على النقطة.

على المدى الطويل ، أنا متأكد من أنهم سيحافظون على تمكينه ، فهم فقط يكتشفون كيفية القيام بذلك.

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

كيف يتفاعل هذا مع Altinstall'd Pythons؟
خاصة مثل تلك المثبتة بأدوات مثل https://github.com/yyuu/pyenv

مخطط المستخدم هو .local/lib/pythonX.Y/site-packages ، لذلك إذا كنت تدير عدة ثعابين بنفس الإصدار الرئيسي / الثانوي ، فقد ينتهي بك الأمر بفوضى على ما أعتقد.

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

مشكلة ذات صلة في redhat / fedora bug tracker https://bugzilla.redhat.com/show_bug.cgi؟id=662034#c10

يبدو أن Fedora / RedHat PATH=$PATH:$HOME/.local/bin:$HOME/bin موجود بالفعل في /etc/skel/.bash_profile . سيؤدي ذلك إلى استمرار ظهور العناصر المثبتة بـ --user بشكل افتراضي ، على الأقل لمستخدمي bash (الصدفة الافتراضية). ربما التوزيعات الأخرى لديها بالفعل هذا؟

لا يوجد شيء مختلف بشكل خاص حول Windows أعرفه. لكننا حصلنا للتو على دليل Python القياسي على مسار الأشخاص ، ولا أتوقع أن الحصول على دليل البرامج النصية لكل مستخدم سيكون سهلاً بشكل خاص - وقد تكون هناك صعوبات تقنية أيضًا ، لست متأكدًا وضع متغير بيئة على مستوى المستخدم مثل %LOCALAPPDATA% في مستوى النظام %PATH% حتى يعمل :-(

أنا ضد التسرع في هذا. أفضل الانتظار حتى نتمتع بخبرة أكبر في عمليات تثبيت المستخدم وتمكنا من حل المشكلات أولاً. أعلم أن هذه مشكلة الدجاج والبيض ، لكنني لا أرى التسرع في التغيير مفيدًا.

أيضًا ، مع قبعة Windows الخاصة بي ، يجب أن أقول إن جعل الأمر أكثر صعوبة بالنسبة لمستخدمي Unix الذين لم يتوصلوا بعد إلى أن الاستخدام غير المبالي لـ sudo يعد أمرًا سيئًا للقيام بأشياء غبية ، وليس هذا مبررًا جيدًا حقًا .. .

أفترض أن هذا لن ينطبق إلا عند تشغيل النقطة من نظام بايثون.

حسنًا ، الشيء المختلف في Windows هو أنه لا يوجد نظام مزود ببايثون كما هو الحال في * لا يوجد والذي يأتي أيضًا مع حزم Python المقدمة من النظام :)

أنا لا أرغب بشكل خاص في التسرع في هذا أيضًا. أردت فقط أن أبدأ المناقشة.

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

عند التحدث إلى أحد أفراد Fedora ، أعتقد أن الطريقة التي يمكن بها القيام بذلك هي تنفيذ فحص الأذونات. إذا كان لدي إذن للكتابة إلى دليل حزم الموقع ، فأنا مستخدم مخصّص ويتم تثبيت النقطة على Python العالمية ، إذا لم يكن لدي إذن ، فأنا مستخدم غير مميز ويتم تثبيته على --user .

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

كما يلاحظ Paul ، فإن PATH على Windows لا يتضمن دليل البرامج النصية للمستخدم _user_ حتى الآن (فقط الدليل العالمي) ، لذلك يستحق هذا بالتأكيد أن يؤخذ في الاعتبار.

لا أرى أي عوائق كبيرة في جانب POSIX بالرغم من ذلك. كيف تبدو فكرة تجربة المستخدم هذه: بالنسبة إلى عمليات التثبيت المستندة إلى العجلة ، تحقق من الأذونات على دليل التثبيت المستهدف ، وإذا لم يكن لدى المستخدم أذونات الكتابة ، فقم بطرح مطالبة تسأل عما إذا كان يرغب في تثبيت المستخدم بدلاً من ذلك؟ ستفرض علامة "- global" أو "--system" الجديدة الإجابة بـ "لا".

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

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

بشكل أساسي ، هذا يجعل وضع الفشل لدينا أفضل بكثير.

مما يجعل الأمر أكثر صعوبة بالنسبة لمستخدمي Unix الذين لم يتوصلوا بعد إلى هذا الاستخدام المهمل لـ sudo
من السيء القيام بأشياء غبية ، أليس هذا مبررًا جيدًا حقًا ..

sudo والأمن هو في الحقيقة مسألة ثانوية IMO.
يتعلق هذا في المقام الأول بمنع التعارض بين حزم نظام التشغيل ونظام النقطة في بيثون النظام.
حاليًا ، غالبًا ما يتم وضع مستخدمي Linux في موقف مستحيل.

1. تفويض نظام التشغيل: 'Use the OS pkg mgr؛ لا تصيب نظامك بحزم مثبتة بنقطة roque (بما في ذلك get-pip 'd pip)'
2. الواقع: "حزم نظام التشغيل (بما في ذلك النقطة) قديمة جدًا ، ولا يمكنني الترقية إلى الإصدار التجريبي من التوزيعة ، فقط للحصول على ترقيات لبعض الحزم. سأذهب إلى المارقة ...."

خطوة أخرى صغيرة هي توثيق (بافتراض أننا نختبرها) أنه يمكنك get-pip.py --user ، وجعل PUG يذكر --user كإمكانية لتثبيت virtualenv (و wheel و twine أيضًا ، إن لم يكن في Virtualenv)

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

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

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

pfmoore ماذا تعتقد أن تجربة مستخدم Windows يجب أن تكون عندما يكون لديك pip install شيئًا ما وليس لديك أذونات للكتابة إلى الدليل؟

FWIW أنا موافق تمامًا على جعل هذا اختياريًا اعتمادًا على Windows أم لا. أنا فقط أتساءل عما إذا كان التحقق من "هل لدي أذونات للكتابة إلى مجلد حزم الموقع" لن يحقق ذلك على أي حال في 99٪ من عمليات التثبيت ، وما إذا كان التثبيت على --user سيكون تجربة أفضل في جزء من الحالات التي لا تملك فيها أذونات الكتابة إلى دليل حزم الموقع.

بمعنى آخر ، إذا تحققنا من الأذونات ، فإن الاقتراح لا يستبدل التثبيت العام بتثبيت مستخدم ، إنه يستبدل خطأ الإذن بتثبيت --user .

لا يحل الاقتراح محل التثبيت العام مع تثبيت المستخدم
يتم استبدال خطأ إذن بتثبيت - مستخدم

حسنًا ، ولكن تذكر أن فكرة التحقق من الأذونات (# 1048) لن تكون أسهل شيء

سيكون الأمر سهلاً للغاية في حالة Wheel ، ويمكننا تغطية الغلاف بنسبة 99.9٪ بأجهزة sdists ، يجب أن تكون مشكلة فقط في الإعداد.

ما رأيك في تجربة مستخدم Windows عندما تقوم بتثبيت شيء ما وليس لديك أذونات للكتابة إلى الدليل؟

حسنًا ، من النادر جدًا أن تكون قادرًا على الكتابة إلى دليل حزم المواقع على نظام Windows لدرجة أنني لست متأكدًا من مدى صلة السؤال في الممارسة العملية. ولكن إذا حدث ذلك ، فسأقول أن هناك خطأ يقول "حزم موقع النظام غير قابلة للكتابة - هل تقصد استخدام --user ؟" سيكون النهج المعقول.

في الواقع ، أعتقد أن هذا سيكون أفضل على Unix أيضًا. يعد تبديل السلوك اعتمادًا على قابلية الكتابة أمرًا غريبًا ، وليس من الواضح بالنسبة لي ما إذا كان استخدام --user لبايثون تم إنشاؤه شخصيًا في دليل قابل للكتابة هو الأسلوب الصحيح (ولكن ليس لدي أي خبرة على الإطلاق في مثل هذا الإعداد ، لذلك ليس لدي أي شيء لدعم هذا الرأي).

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

النهج الذي يقترحه بول هو تقريبًا ما كان يدور في ذهني ، ولكن مع مطالبة بنعم / لا بدلاً من إنقاذ برسالة خطأ. هناك إيجابيات وسلبيات لهذين النهجين (تتعلق في الغالب بكيفية فشلهما عند الاستدعاء من نص آخر).

هل من الممكن إضافة شيء مثل sys.localprefix إلى Python (أرى python-dev هنا)؟
سيكون Sys.localprefix افتراضيًا على sys.prefix. يمكن أن تحدده Distros بنفس الطريقة التي تحدد بها البادئة (مثل البادئة = '/ usr' ، localprefix = '/ usr / local'). قد يستخدم Pip و easy_install sys.localprefix كموقع للتثبيت عليه إذا تم استخدامه كـ sudo ، إذا لم يكن لديهم حقوق كافية تعود إلى المستخدم.

لقد فعلنا شيئًا من هذا القبيل مع "تثبيت الأحجار الكريمة" في Fedora 17 وكان تطوير Ruby عمومًا راضين جدًا عنه ، لذلك اعتقدت أنني سأشارك:

• يقوم "gem install foo" بتثبيت "foo" في ~ / somedir إذا كان uid! = 0
• يقوم "gem install foo" بتثبيت "foo" في / usr / local / somedir إذا كان uid == 0
• تقوم "yum install rubygem-foo" بتثبيت RPM-packaged "foo" في / usr / somedir

أعتقد أن اختيار تثبيت dir بناءً على امتيازات المستخدم سيكون مربكًا جدًا للأشخاص ؛ يجب أن تعمل "pip install foo" بنفس الطريقة لجميع المستخدمين الذين لا يمتلكون جذرًا. إذا كنت تفكر في غالبية المستخدمين ، فسوف يرغبون في "تثبيت نقطة" في منازلهم و "تثبيت sudo pip" في مسار على مستوى النظام. لذلك أعتقد أنه أفضل طريقة للقيام بذلك بناءً على uid كما هو موضح أعلاه - وبالنسبة لأولئك المستخدمين الذين ليسوا جذرًا ولكنهم يريدون التثبيت في dir على مستوى النظام ، هناك دائمًا الخيار --target.

bkabrda ، هذا خيار سهل اتخاذه طالما أنك لست قلقًا بشأن إضافة نصوص إلى $ PATH. ماذا فعلت هناك؟

Ivoz كما لاحظ dstufft ، لدى Fedora بالفعل $ HOME / .local / bin على PATH ، لذلك نجح كل شيء خارج الصندوق (عند الحديث عن البرامج النصية).

يبدو اقتراح Slavek جيدًا بالنسبة لي لأنظمة POSIX. يجب أن تعمل أيضًا بشكل جيد مع الحاويات ، حيث يمكن إخبار الأشياء التي تعمل في حاوية بأنها تعتقد أنها مائلة 0 ، على الرغم من أنها شيء آخر بالكامل من خارج الحاوية.

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

يحتوي Windows أيضًا على غرابة استنادًا إلى ما إذا كان Python مثبتًا في الموقع الافتراضي (غير المتحكم فيه) أو في Program Files (يلزم تصعيد امتياز UAC لإجراء التغييرات).

فكرة "localprefix" التي اقترحها @ rkuska تبدو لطيفة بالنسبة لي ، بسيطة وسهلة. أحب أيضًا الطريقة التي يقترحها bkabrda ، خاصةً بالنسبة للتوزيعات مثل Arch التي تجعل python 3.x python الافتراضي.

ملاحظة أخرى هي أن Arch قد عطّل ensurepip في الإصدار 3.4.0 تمامًا مثل Debian (في الغالب لأننا نريد توفير أحدث إصدارات من setuptools و pip ، في حين أن الإصدارات المجمعة قد تكون قديمة بالنسبة للأعمار) ، لذلك سيكون من الجيد الحصول عليها نصيحة لذلك.

تضمين التغريدة
بالنسبة إلى Arch ، لم نقم بإضافة أي مسار أسفل $ HOME إلى PATH ، لكنني ما زلت أعتقد أنه جيد. لدينا بالفعل إدخال wiki لـ Ruby يخبر المستخدم بإضافته.

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

فقط لمعلوماتك ، لدينا بالفعل إصدارات Python 3.4 RPM العاملة في نظام بناء Copr الخاص بـ Fedora (اختبار ، لا ينصح بتثبيتها إذا كنت لا ترغب في كسر أي شيء). إذا كنت تريد معرفة المزيد حول كيفية تعاملنا مع هذا ، فقم بإلقاء نظرة على الكود وما إلى ذلك ، راجع مناقشتي مع Barry Warsaw [2] في debian-python ML.
(لا تزال تصحيحاتنا بحاجة إلى بعض الحب قبل أن نقترحها في اتجاه المنبع ، ولكن كل شيء يعمل بشكل جيد بالنسبة لنا أجهزة الصراف الآلي في اتجاه المصب)

[1] http://copr-fe.cloud.fedoraproject.org/coprs/bkabrda/python-3.4/
[2] https://lists.debian.org/debian-python/2014/03/msg00046.html

عذرًا ، لكن AFAIK Arch لم يدعم العجلة مطلقًا ، ولا نريد أن نجعل ensurepip يستدعي مدير الحزم (صححني إذا فهمت أن هذا النهج خاطئ ، رغم ذلك).

بالنسبة لـ ensurepip ، سيكون من الجيد تحذير المستخدم من تثبيت pip باستخدام ensurepip على الرغم من ذلك ، وهذا أكثر ما يمكنني التفكير فيه في الوقت الحالي.

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

felixonmars هل هذا يعني أنه على Arch venv تم كسره كما هو الحال في دبيان؟

حسنًا ، شكرًا على الشرح ، أعتقد أنني خطرت في ذهني الفكرة. سأرى ما يمكنني فعله ومتابعة debian-python لهذا الغرض.

dstufft نعم ، تم تثبيت الإصدار المجمع بدلاً من إصدار النظام.

bkabrda حتى يحل هذا المشكلة إذا كنت تستدعي النقطة باستخدام نظام Python ، يتعين علينا استخدام حالة خاصة virtualenv / venv في هذه الحالة (وهي ليست نهاية العالم). ولكن هذا يعني أيضًا أننا نفترض أن جميع Pythons هي Pythons للنظام ، حتى تلك التي تم تثبيتها بواسطة المستخدم في homedir الخاصة به مثل https://github.com/yyuu/pyenv (وهي طريقة تشغيل Python في الواقع). لذلك لست متأكدًا ، لهذا فكرت في التحقق من الإذن.

كما قال dstufft ، باستخدام أداة مثل pyenv للتوفيق بين الثعابين غير الجذرية ، سيكون من الغريب جدًا أن يكون root هو المفتاح لإجراء تثبيت عالمي (حيث "global" ! = "النظام")

لقد فعلنا شيئًا كهذا باستخدام "تثبيت الأحجار الكريمة" في Fedora 17

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

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

آه @ Felixonmars لقد رأيت للتو https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD؟h=packages/python ، إذا كان كل ما تفعله هو الاتصال بـ --without-ensurepip فلا بأس بذلك . هذا يترك وحدة ensurepip سليمة لوحدة venv. تصحيحات Ubuntu (Debian؟) الموجودة حاليًا تستدعي rm -rf على حزمة ensurepip نفسها ، مما يجعلها غير متاحة ليتم استدعاؤها داخل venv.

أعتقد أن التقصير في تثبيت المستخدم قد اقترحه نيك قبل عامين ، أو ربما شخص آخر منذ فترة طويلة ، لكن الخيط ذهب في اتجاهات عديدة ولم يكن مثمرًا. كانت العقبة الرئيسية هي المتخلفة المتوافقة مع IIRC ، ولكن في هذه الأيام قد يكون مستخدمو النظام والنقاط أكثر استخدامًا للحذر مع تحديثات virtualenv / pip / setuptools ، للأفضل أو للأسوأ. لا أتذكر ما إذا كانت هذه المناقشة قد حدثت في distutils-sig أو pypa-dev.

كان كتالوج سيج: https://mail.python.org/pipermail/catalog-sig/2013-F February/004773.html

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

felixonmars حسنًا ، المشكلة هي أنه لا يمكنك تثبيت حزمة نظام في Virtualenv afaik :) (وحتى إذا كان بإمكانك أن تكون هناك مخاوف مختلفة بشأن ما تريده في حزمة النظام مقابل داخل Virtualenv)

dstufft هذا هو المكان الذي يبدأ فيه إعادة عجلة Slavek ، لكن هذا بعيد بعض الشيء :)

نعم ، تحقق من الجزء الأخير من https://lists.fedoraproject.org/pipermail/python-devel/2014-March/000583.html :(

@ dstufft شكرا!

لست متأكدًا مما إذا كان يجب أن أواصل المناقشة هناك ، لأن ذلك لا ينبغي أن يكون مشكلة لأننا لم نفكك نقطة في القوس ، ويجب أن تولد إعادة التدوير عجلة قابلة للاستخدام :)

dstufft أنت محق في أننا ربما نحتاج إلى specialcase virtualenv وربما حتى pyenv ، الذي يبدو قبيحًا. يجب أن أعترف أنني لست على دراية بـ pyenv ، لذلك لا يمكنني التفكير في أي حل "مناسب" لذلك الآن. سأحاول إلقاء نظرة فاحصة عليها والتفكير في شيء ما.

qwcode لـ "تثبيت الأحجار الكريمة" على Fedora ، إنه تصحيح نهائي. TBH لم أتطرق إلى Rubygems فيدورا لفترة طويلة ، لكن في المرة الأخيرة التي تحققت فيها ، كان المصب فقط.

لقد نشرت رابطًا لهذه المشكلة للخلل ذي الصلة في بيثون [1]. أرغب في نقل هذه المناقشة إلى python core ، للحصول على موقع قابل للتكوين لعمليات التثبيت المحلية ليس فقط pip ولكن أيضًا easy_install و python setup.py install ، بعد هذه النقطة يمكن استخدام ( على سبيل المثال) sys.localprefix dir if uid==0 وقم بالتثبيت إلى user dir إذا كان uid!=0 كما ذكر bkabrda .

في الوقت الحالي ، أنا بخير مع تثبيت النقطة على user dir بشكل افتراضي.

[1] http://bugs.python.org/issue1298835

كما أشار نيك ، نقلت المناقشة من الإصدار 128835 إلى pypa-dev [1].
[1] https://groups.google.com/forum/#!topic/pypa -dev / r6qsAmJl9t0

افتراضي إلى --user

فكره جيده!

سيظهر خطأ pip install foo لأنه لا يمتلك أذونات الملف. يؤدي هذا إلى قيام الأشخاص بدلاً من ذلك بتشغيل sudo pip install foo والذي يتم تثبيته عالميًا على نظام Python

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

1. أرسل بريدًا إلكترونيًا إلى المسؤول واطلب منه تثبيت الحزمة. هذا بطيء ومضجر للجميع.
2. استسلم واستغني عن الحزمة.

فقط إذا كانوا من ذوي الخبرة أو المطلعين بشكل خاص ، فسيحاولون pip install --user .

إذا انتهى بنا الأمر إلى اتخاذ قرار ضد "التقصير إلى - المستخدم" ، فيجب أن نفكر في البدائل الأقل اضطرابًا:

1. الرجوع إلى المستخدم (في حالة فشل التثبيت بسبب أخطاء الإحاطة)
2. (إذا فشل التثبيت بسبب أخطاء محيطية) ، شجع المستخدم (بأحرف كبيرة ودية) لمحاولة --user

لقد كنت أستخدم بالفعل --user في جميع عمليات التثبيت الخاصة بي لفترة من الوقت الآن ، لكن بشكل عام لا يعرف الناس هذا الخيار. أوافق على أنه من المزعج رؤية خطأ الأذونات في كل مرة تنسى فيها هذا الخيار. لقد لاحظت أن عمليات تثبيت المستخدم غير متوافقة مع conda على الرغم من (conda / conda # 448).

أرغب في إحياء هذا ، لأن الناس سوف يتعاملون معه على Windows في كثير من الأحيان الآن بعد أن 3.5 الإعدادات الافتراضية للتثبيت في Program Files (والتي تتطلب امتيازات المسؤول للتعديل).

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

هدفي هو أن يتمكن المستخدم غير المطلع من تنفيذ pip install spam; python -c "import spam" بدون أخطاء (على الرغم من أنه قد يكون تحذيرًا عند إعادة المحاولة باستخدام --user ).

لقد كنت أفكر في هذا مؤخرًا خاصةً منذ فتح # 2403 و # 2401 مؤخرًا مما جعلني أفكر في استخدام sudo pip install وكيف يمكن أن يؤدي ذلك غالبًا إلى كسر الأنظمة خارج مشاكل الأذونات فقط.

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

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

سؤال مهم آخر هو ما الذي يجب أن نفعله إذا اكتشفنا أن Python التي نقوم بتثبيتها لا تحتوي على مواقع مستخدمين ممكّنة. في هذه الحالة ، أود ببساطة أن أذكر أن --user خطأ ، وبالنسبة لتلك Pythons ، فإننا ببساطة نعود إلى التقصير إلى --global . سيغطي هذا Virtualenv / venv التي أؤمن بها تلقائيًا ، وإذا أراد شخص ما بيئة معزولة للوزن "أثقل" باستخدام Pythons المجمعة بالكامل ، فيمكنه ببساطة تصحيح site.py بحيث يقوم بتعيين ENABLE_USER_SITE إلى False أعلى الملف.

+1 ، وسأصوت لنظام -.

سألاحظ ، وأنا متأكد من أنك ستحب هذا ، فقد تم تغيير الإعداد الافتراضي لـ Ubuntu:

https://launchpad.net/ubuntu/+source/python-pip/1.5.6-4ubuntu1

في 09 فبراير 2015 الساعة 04:41 مساءً كتب دونالد ستافت:

تحقيقًا لهذه الغاية ، أتساءل عما إذا كان الهدف النهائي الأفضل ليس فقط أن --user هو
افتراضي ، لا توجد فحوصات أذونات سحرية ، وأضف علمًا جديدًا مثل --global ،
--system أو --no-user والذي سيعيد السلوك السابق. هذه
من السهل شرحه للناس لأنه سيكون له نفس السلوك بغض النظر
كيف / أين يتم تثبيت الأشياء.

أعتقد أن --system خطأ لأن ذلك ينطبق فقط على بعض بايثون. لا تنطبق على:

• Python على نظام Windows
• تثبيت Pyenv Pythons
• قامت Conda بتثبيت Pythons
• تثبيت لا شىء Pythons
• تم تجميع Pythons المخصصة.

يتم تطبيقه _ فقط_ على أنظمة * nix حيث يتم شحن Python بواسطة النظام. أشعر أن --global هو اسم أفضل بكثير لهذا العلم.

و FML ، لماذا يشعر Debian / Ubuntu بالحاجة إلى إضافة تصحيحات عشوائية باستمرار لكسر حالات الاستخدام المتوقعة؟

لذا إذا تم إرجاع تصحيح Ubuntu ، فما هو المخطط الزمني لإصلاح هذا هنا؟ اسبوع / شهر / 3 اشهر / 6 اشهر / سنه ...؟

يعتمد ذلك على ما تقصده بكلمة ثابتة.

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

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

لن يمنع هذا أي شخص من استخدام sudo pip install foo في نظام Python الخاص به ، ومع ذلك فإنه سيطبع تحذيرًا بأنه في مرحلة ما سيعني هذا --user ويطلب منهم البدء صراحة في استخدام --global . بمجرد إصدار ما سبق لفترة طويلة بما يكفي ، يمكننا بعد ذلك إزالة مسار الكود المهمل وتبسيط ذلك بحيث يكون ببساطة:

• عندما يتم تمرير --user نقوم _ دائمًا_ بالتثبيت في حزم موقع المستخدم.
• عندما يتم تمرير --global (أو أيًا كان) ، نقوم _ دائمًا_ بالتثبيت في حزم الموقع العالمية.
• عندما لا يتم تمرير أي من الخيارين ، فإننا نطبق طريقة احتياطية والتي:
  
  
  
  • يكتشف ما إذا كنا في بيئة افتراضية وإذا كان الأمر كذلك يتصرف كما لو تم تمرير --global .
  
  
  • يكتشف ما إذا كانت حزم موقع المستخدم معطلة وإذا كان الأمر كذلك يتصرف كما لو تم تمرير --global .
  
  
  • أخيرًا يستخدم --user كخيار افتراضي.
  
  

ومع ذلك ، فإن الانتقال من السلوك الأول إلى السلوك الثاني سيكون له جدول زمني طويل إلى حد ما. سيكون هذا تغييرًا كبيرًا حقًا سيؤدي إلى كسر الأشياء لأي برنامج (مثل الملح أو الشيف أو الدمى) أو سيناريو نشر (مثل نصوص مخصصة من القماش مخبوزة في آلاف المشاريع في جميع أنحاء العالم) والتي تتوقع ذلك سيتم تثبيت sudo pip install <foo> في Python العالمية. سنحتاج إلى منح الأشخاص مهلة طويلة حتى يتمكنوا من رؤية التحذير ، وتعديل برامجهم ونصوصهم لتمرير علامة --global صريحة إذا كانوا بحاجة فعلاً إلى هذا السلوك.

أعتقد أن خطة دونالد المقترحة هي خطة جيدة ، على الرغم من أنه إذا قرر فريق النقطة اعتماد هذا النهج ، فيجب علينا أيضًا تقديم مشكلة مانع الإصدار 3.5 مع CPython لإضافة دليل البرامج النصية لكل مستخدم إلى المسار على Windows جنبًا إلى جنب مع العمومية. واحد. إذا أضاف 3.5 ذلك جنبًا إلى جنب مع التبديل إلى التثبيت في Program Files افتراضيًا ، فيجب أن نحصل على السلوك المطلوب للتثبيت دون استمرار أذونات المسؤول في "العمل فقط".

قد تكون القدرة على تغيير موقع التثبيت الافتراضي عبر ملفات تهيئة النقطة مفيدة أيضًا ، مما يسمح للأشخاص بالاشتراك في "لكل مستخدم افتراضيًا" على أنظمتهم الخاصة ، حتى إذا لم يتغير الوضع الافتراضي بعد. (على سبيل المثال ، "default-install = user" مقابل "default-install = global")

@ dstufft : يسعدني أن أقدم المساعدة لتنفيذ اقتراحك كما قيل في علة أوبونتو إذا كنت بحاجة لي. بمجرد أن نحصل على هذا السلوك في صندوق الأمتعة ، سأقوم باستبدال تصحيح أوبونتو الحالي بهذا بالطبع.

ابقني على اطلاع إذا كنت بحاجة إلى أي مساعدة.

أنا +1 في خطة dstufft . سأختار --global كاسم للأسباب المذكورة. لقد جلسنا على السياج لفترة كافية الآن ، دعنا نذهب إليه.

O'n و +1 على اقتراحncoghlan بأن تضيف Python 3.5 دليل موقع المستخدم إلى PATH على Windows. دعونا نتجنب أي عقبات أخرى لهذا الانتقال.

أنا أيضًا أقوم بإجراء +1 لخطةdstufft و +1 لـ --global ، على الرغم من أنني ما زلت أتساءل عن sudo pip install foo الذي يحتاج إلى --global . هل هناك في الواقع أي حاجة للجذر للحصول على حزم موقع المستخدم؟ هل يمكننا جذر حالة خاصة لإيقاف حزم الموقع افتراضيًا؟ (مما يجعل sudo pip install foo يعمل تمامًا كما هو الحال الآن)

لم أر أبدًا أي شخص يستخدم --user للجذر مع الحالة الحالية ، ولكن إذا كان شخص ما يعرف بالفعل حالة الاستخدام هذه ، أود أن أعرف.

أحد الأفكار التي خطرت لي هي كيف سيعمل دليل موقع المستخدم مع إصدارات متعددة من Python مثبتة؟

إذا قمت باستخدام pip install pytest --user في Python 2.7 و 3.4 (مع Python 3.4 ، فإن Python الافتراضية الخاصة بي) ، فما الإصدار الذي سيتم تنفيذه بواسطة الأمر py.test ؟ لدي شك في أن التثبيتين سيحلان محل بعضهما البعض ، لذا فهو موقف "يفوز الأخير" ، وهو _ ليس جيدًا. أيضًا ، إذا كان "آخر واحد يربح" ، وقمت بتثبيت الإصدار 2.7 بعد الإصدار 3.4 ، فكيف يمكنني إصلاح ذلك لجعل الإصدار 3.4 هو الإصدار الافتراضي مرة أخرى؟

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

    C:\Apps\Python34\python.exe -m pip install pytest --user
    C:\Apps\Python27\python.exe -m pip install pytest --user
    C:\Apps\Python34\python.exe -m pip uninstall -y pytest

أولاً ، لماذا لم يصدر الأمر الثاني تحذيرًا بأنه تم استبدال ملف موجود؟ أم أنها؟ سواء حدث ذلك أم لا ، هل لدي أي خيارات بشأن ما يجب القيام به؟

ثانيًا ، ألا تفشل عملية الإزالة لأن المجموع الاختباري لـ py.test.exe لن يتطابق مع القيمة الموجودة في الملف RECORD ؟ إذا فشل ، كيف يمكنني إلغاء التثبيت؟ إذا لم تفشل ، فهل ستكسر نسخة Python 2.7 الخاصة بي من pytest (عن طريق حذف exe)؟

وأخيرًا (في الوقت الحالي!) هل سينتقل دليل البرامج النصية للمستخدم قبل أو بعد دليل البرامج النصية للنظام في PATH؟ يجب أن تتبع IMO ، وإلا فإن تثبيت المستخدم لحزمة في Python لم يطلبه المستخدم ليكون "Python الافتراضي" يمكنه تجاوز نفس الحزمة المثبتة في حزم مواقع نظام Python "الافتراضية".

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

أتوقع أن يتم التعامل مع تعارض الأسماء في دليل البرنامج النصي لمستخدم Windows المشترك بنفس الطريقة التي يتم التعامل بها مع أنظمة POSIX مع دلائل bin المشتركة الخاصة بهم: لن يقوم Python 3 بتثبيت اسم البرنامج النصي غير المؤهل للحزم المثبتة ، لذلك سيشير الاسم إلى إصدار Python 2.

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

"لن يقوم Python 3 بتثبيت اسم البرنامج النصي غير المؤهل للحزم المثبتة" - من المفترض أنك تقصد أن pip و setuptools (في Python 3) لن تفعل ذلك هنا؟ إذن هذا تغيير لتلك الأدوات؟

أوه ، وبله. تم تدريب ذاكرتي العضلية بنسبة 100٪ على كتابة "pip install foo" لتثبيتها في لغة Python الافتراضية (3.4). سيكون ذلك جحيمًا لإعادة التدريب.

أيضًا ، يمكن لمستخدمي Windows اختيار ما إذا كانت كلمة python تعني Python 2 أو 3 (عبر "اجعل هذا هو Python الافتراضي" و "Add to PATH") - بخلاف مستخدمي Unix حيث يضع نظام Python القواعد. إذا قلت إنني أريد أن أجعل Python 3.5 افتراضيًا ، فلماذا لا تشير كلمة "pip" (أو أي اسم آخر غير مؤهل) إلى هذا الإصدار؟ يبدو من الغريب أن مستخدمًا مثبتًا عليه Python 3.5 فقط على Windows لا يمكنه استخدام أسماء غير مؤهلة لمجرد وجود مشكلة في Unix تتعلق بكيفية احتياج نظام Python للأشياء المسماة. (أعتذر إذا كان وصفي لقيود Unix غير دقيق - فأنا لا أفهم المشكلة هناك حقًا). يحتاج الأشخاص الذين يقومون بتثبيت إصدارات متعددة من Python إلى حل ، ولكن لا ينبغي أن يؤثر هذا الحل على الأغلبية الذين يحتاجون فقط إلى إصدار واحد.

ربما تكون أبسط إجابة هي أن دليل البرامج النصية للمستخدم يجب أن يكون له إصدار ، تمامًا مثل دليل حزم موقع المستخدم؟

أوه ، وهل يجب أن يكون هذا النقاش على python-dev بدلاً من هنا ، لأنه بشكل عام يتعلق بدليل موقع المستخدم؟

من المؤكد أن إعادة فتح مناقشة تصميم PEP 370 لدليل البرامج النصية لنظام Windows لكل مستخدم على python-dev من الغريب أن يتم تحديد نطاق تثبيتات البرامج النصية العالمية على Windows بواسطة إصدار Python ، لكن عمليات تثبيت البرامج النصية لكل مستخدم ليست كذلك.

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

بقدر ما يذهب الحل العام للتعامل مع التثبيت المتوازي ، سيكون هذا هو المفتاح "-m" - وبهذه الطريقة تعرف دائمًا أي لغة Python تستدعيها ، بدلاً من التخمين حول محتويات سطر shebang المنفصل.

فهم re -m ، ولكن في المرة الأخيرة التي تم طرحها في سياق كيفية توثيق الأشياء ، كان التفضيل القوي هو أننا يجب أن نتعامل مع pip install foo كطريقة أساسية لتثبيت الأشياء (باستخدام -m يتم التعامل مع الأوامر التي

لا يشير دليل النقطة حتى إلى البدائل (باستثناء حالة استخدام -m لترقية النقطة نفسها على Windows).

أوصي بـ -m في مستندات حزمة stdlib للتعامل مع استدعاء النقطة عندما
التعامل مع تثبيتات Python المتوازية - إنه أسلوب الاستدعاء الوحيد الذي
يعمل عبر جميع الأنظمة الأساسية ، لعمليات التثبيت العالمية ، وتثبيتات المستخدم والظاهرية
البيئات.

في 09 شباط (فبراير) 2015 ، في الساعة 07:58 مساءً ، كتب نكوجلان:

القدرة على تغيير موقع التثبيت الافتراضي عبر ملفات تهيئة النقطة
قد يكون مفيدًا أيضًا ، حيث يسمح للأشخاص بالاشتراك في "افتراضيًا لكل مستخدم"
أنظمتهم الخاصة ، حتى لو لم يتغير الإعداد الافتراضي
بعد. (على سبيل المثال ، "default-install = user" مقابل "default-install = global")

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

https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1419695
http://bugs.debian.org/cgi-bin/bugreport.cgi؟bug=725848

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

لا أعتقد أن Debuntu يقوم حاليًا بتثبيت ملف pip.conf على مستوى الموقع (سآخذ
للتحقق مرتين).

https://pip.pypa.io/en/latest/user_guide.html#configuration

أحد المضاعفات: نقوم بتثبيت برامج نصية مختلفة لـ Python 2 و Python 3 ،
لذلك أعتقد أننا سنحتاج إلى ملفات تكوين منفصلة للإصدارات المختلفة من
Python ، على سبيل المثال /etc/{xdg/pip/}/pip{2،3}.conf أو بعضها.

في 10 فبراير 2015 الساعة 01:24 صباحًا ، كتب بول مور:

أحد الأفكار التي خطرت لي هي كيف سيعمل دليل موقع المستخدم
إصدارات متعددة من Python مثبتة؟

على Debian / Ubuntu (ربما كل * nixes؟) ليس لدينا تصادم لأن ملف
يتم تثبيت المكتبات في حزم ~ / .local / lib / pythonX.Y / site

نحن _do_ نحصل على تصادمات على ~ / .local / bin. يتم تثبيت حزمة بامتداد
البرنامج النصي "foo" باستخدام pip install --user foo و pip3 install --user foo will
ينتهي الأمر بضرب البرنامج النصي ~ / .local / bin / foo.

أحد الجوانب السلبية لهذا التغيير هو أنني أعتقد أن Fedora هو التوزيع النهائي الوحيد الذي يضيف ~/.local/bin إلى $PATH افتراضيًا (ويجب أن يأتي قبل / usr / bin و / usr / local / bin فقط مثل حزم موقع المستخدم التي تأتي قبل حزم الموقع). من الناحية المثالية ، سيتمكن المصب من تعديل أنظمته بحيث يكون ~/.local/bin على $PATH افتراضيًا.

في 10 فبراير 2015 ، في الساعة 07:24 صباحًا ، كتب دونالد ستافت:

أحد الجوانب السلبية لهذا التغيير هو أنني أعتقد أن فيدورا هو المصب الوحيد
توزيعة تضيف ~/.local/bin إلى $PATH افتراضيًا (ويجب أن يأتي
قبل / usr / bin و / usr / local / bin تمامًا مثل حزم موقع المستخدم
قبل حزم الموقع). من الناحية المثالية ، سيتمكن المصب من تعديل ملفات
أنظمة بحيث يكون ~/.local/bin على $PATH افتراضيًا.

نعم ، ولكن يمكننا اتخاذ قرار منفصل بشأن ذلك. (أو بالأحرى المصب
يمكن أن تفعل ذلك.)

(ويجب أن يأتي قبل / usr / bin و / usr / local / bin تمامًا مثل المستخدم
حزم الموقع تأتي قبل حزم الموقع)

حسنًا ، ncoghlan قال العكس تمامًا ، (على Windows ، على وجه التحديد
السياق) يجب أن يكون دليل البرامج النصية للمستخدم _ بعد_ دليل النظام. أي
أوافق على ما دام دليل البرامج النصية للمستخدم غير محسوب. إذا كان كذلك
تم إصداره ، فأنا أقل قلقًا. لكن هذا ربما يعكس حقيقة ذلك
لم يحتاج مستخدمو Windows أبدًا لتحمل تصادم الخراطيش غير المحسوبة و
الأشياء الفظيعة مثل pip2 / pip3 ، الطريقة التي يستخدمها مستخدمو Unix ؛-)

أوه ، والشيء الناجم عن البرنامج النصي هو مشكلة عامة لا تتعلق حقًا بـ --user تمامًا. توجد نفس المشكلة في كل مكان باستثناء تثبيت Windows --global . أعتقد أن حل هذه المشكلة هو مشكلة / مشكلة ثانوية يجب أن نحلها بشكل منفصل لهذه المشكلة.

الأفكار الحالية:

• أعتقد أن هناك اتفاقًا على الفكرة العامة التي نشرتها سابقًا ، لذلك أعتقد أننا نريد المضي قدمًا في شيء من هذا القبيل.
• سنستخدم العلم --global .
• من المحتمل أننا نريد نوعًا من التحذير إذا قمنا بالتثبيت في --user و ~/.local/bin ليس على $PATH .
• سنرغب في نوع من الخيار default-install الذي سيعطل بشكل أساسي السلوك الاحتياطي والشفرة الثابتة إما --global أو --user .
• اعتبارًا من pip 6.0 ، لدينا ملفات تكوين خاصة بالماكينة موجودة في /etc/ ولكن هذه ليست خاصة بإصدار Python الذي يقوم بتنفيذ pip. أعتقد أن هذه ميزة جيدة على الرغم من أنها منفصلة إلى حد ما أيضًا (وقد تتماشى جنبًا إلى جنب مع حل مشكلة clobbering الخاصة بالبرنامج النصي أيضًا).

لا يزال هناك سؤال رئيسي مفتوح: ماذا نريد أن يحدث على المدى الطويل عندما يفعل شخص ما sudo pip install foo أو بالأحرى ، إذا كان لدى شخص ما الإذن بالكتابة إلى الدليل site-packages ؟

الخيارات التي يمكنني التفكير فيها هي:

1. التثبيت في --global . هذا هو الخيار الأكثر توافقًا مع الإصدارات السابقة ويمثل على الأرجح ما يتوقعه المستخدمون عند كتابته. ومع ذلك ، فإن له جانبًا سلبيًا في أنه سوف يعبث (بصمت) مع Python العالمية ، والذي يمكن أن يتسبب في أنظمة معطلة في العديد من الأنظمة.
2. قم بالتثبيت في --user ، وهذا سيحمي من الأنظمة المعطلة (أعتقد؟) ولكن لا أعتقد أن أي شخص يتوقع أن يحصل المستخدم الجذر على تثبيت /root/.local/ .
3. فقط حدث خطأ وتطلب من المستخدم تحديد إما --user أو --global يدويًا.
4. اختر أحد الخيارين الأولين ، ولكن وفر مفتاحًا يمكن أن تقوم التوزيعات بتشغيله بـ /etc/ والذي سيمكن الخيار الثالث.

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

أشعر أن الخيار الثالث من المحتمل أن يكون سيئًا ، نظرًا لأن "لدي إذن الكتابة" سيكون سيناريو وجود أي شخص على نظام التشغيل Windows على ما قبل Python 3.5 ، أو أي شخص يستخدم Conda ، أو أي شخص يستخدم pyenv. يبدو أن الخطأ في الخروج هو الشيء الخطأ الذي يجب القيام به في كل هذه الحالات وهو أمر غير مألوف للمستخدم للتمهيد.

لذلك أعتقد أن ما بين 1 و 2 يرجع حقًا إلى مدى سوء الممارسة التي نعتقد أنها (من الناحية النظرية) يقوم بها الأشخاص sudo pip install --global foo . على أنظمة التشغيل Windows ، و Conda ، و pyenv ، وما إلى ذلك ، أشعر أن الإجابة على ذلك هي "لا نعتقد أنها ممارسة سيئة على الإطلاق". في * لا شيء أشعر أن الإجابة هي "يجب السماح للمستخدمين بفعل ما يريدون لنظامهم ولكن يجب أن نوفر القضبان لإبعادهم عن الأشياء" السيئة ".

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

إذن ، سيكون اقتراحي المحدث:

• عندما يتم تمرير --user نقوم دائمًا بالتثبيت في حزم موقع المستخدم.
• عندما يتم تمرير --global نقوم دائمًا بالتثبيت في حزم الموقع العالمية.
• عندما لا يتم تمرير أي منهما ، فإننا نطبق طريقة احتياطية والتي:
  
  
  
  1. يكتشف ما إذا كنا في بيئة افتراضية وإذا كان الأمر كذلك يتصرف كما لو تم تمرير --global .
  
  
  2. يكتشف ما إذا كانت حزم موقع المستخدم معطلة وإذا كان الأمر كذلك يتصرف كما لو تم تمرير --global .
  
  
  3. ينظر إلى default-install وإذا كان موجودًا يستخدم --user أو -global بناءً عليه.
  
  
  4. يكتشف ما إذا كان المستخدم الفعال ليس لديه أذونات الكتابة إلى حزم الموقع العالمية ، وإذا كان لا يتصرف كما لو تم تمرير --user .
  
  
  5. أخيرًا ، إذا فشلت جميع طرق الكشف الأخرى ، فتصرف كما لو تم تمرير --global .
  
  

هذا يعني عدم وجود فترة إهمال وأن التوقع هو أنه في حالة عدم وجود --user أو --global ، سنحاول تقديم أفضل تخمين بناءً على إمكانيات Python التي نستخدمها والمستخدم الفعال وأي طريقة تثبيت افتراضية مهيأة.

(ويجب أن يأتي قبل / usr / bin و / usr / local / bin تمامًا مثل المستخدم
حزم الموقع تأتي قبل حزم الموقع)

حسنًا ، ncoghlan قال العكس تمامًا ، (على Windows ، على وجه التحديد
السياق) يجب أن يكون دليل البرامج النصية للمستخدم _ بعد_ دليل النظام. أي
أوافق على ما دام دليل البرامج النصية للمستخدم غير محسوب. إذا كان كذلك
تم إصداره ، فأنا أقل قلقًا. لكن هذا ربما يعكس حقيقة ذلك
لم يحتاج مستخدمو Windows أبدًا لتحمل تصادم الخراطيش غير المحسوبة و
الأشياء الفظيعة مثل pip2 / pip3 ، الطريقة التي يستخدمها مستخدمو Unix ؛-)

أنا لا أفكر حتى فيما يتعلق بتضارب أسماء البرامج النصية. أعتقد أنه من الخطأ تمامًا أن يتصرف المتغير $PATH بشكل مختلف عن المتغير sys.path . بقدر ما أعرف أن طلب sys.path هو: stdlib> حزم موقع المستخدم> حزم المواقع العالمية. أعتقد أنه سيكون محيرًا حقًا إذا كان طلب some-script هو global bin dir> user bin dir بينما python -m some-script كان حزم موقع المستخدم> حزم المواقع العالمية.

إذا كانت هناك مشكلة في أدلة البرنامج النصي (والإصدار مقابل غير الإصدار) ، فأعتقد أنه يجب علينا حل هذه المشكلة ولكنها ليست ذات صلة كبيرة بالترتيب الذي يجب أن تكون فيه ، لأنني أشعر بأي شيء آخر غير مطابقة ما sys.path هل هو خاطئ للغاية.

نقطة جيدة ، يجب أن نفترض (ونوصي) أن $ PATH يتبع sys.path ، مع (في مصطلحات Windows) C: PythonXY قبل٪ APPDATA٪ PythonXYScripts قبل C: PythonXYScripts. سألاحظ ذلك في موضوع python-dev.

يبدو اقتراح دونالد الأخير جيدًا بالنسبة لي (مثل اقتراحي الأصلي بالإضافة إلى جميع التفاصيل المهمة التي تركتها :)). أوافق بنسبة 100٪ مع الفقرة "لذا أفكر في الأمر أكثر ..." أيضًا.

بالنسبة لتكوين PATH على Windows ، سيكون ذلك مستحيلًا تقريبًا. يمكن للمثبت على مستوى النظام تكوين متغيرات البيئة على مستوى النظام فقط ولا يمكن أن تتضمن توسعات ، لذلك لا يمكنك تعيين مسارات مختلفة لكل مستخدم. (يمكن للمثبت لكل مستخدم القيام بذلك ، ولكن في هذه الحالة سينجح --global وبالتالي ليست هناك حاجة.)

أيضًا ، بسبب معالجة Windows المعطلة PATH ، فإن الإعدادات على مستوى النظام _ دائمًا_ تتفوق على الإعدادات لكل مستخدم. أدى هذا إلى اقتراحي النصف (على python-dev، IIRC) حول استخدام مشغل py.exe للنصوص غير المنسوخة ، بحيث يذهب pip.exe دائمًا إلى أحدث نظام أو مستخدم Python بدلاً من واحد قام بتثبيته ، و (على سبيل المثال) pip.exe -3.5 سيسمح باختيار إصدار معين.

الطريقة الوحيدة لإنجاح هذا الأمر هي أن يبدأ مُثبِّت Python في تثبيت ملفات دُفعات لتكوين PATH عند الطلب (وربما اختصارًا يقوم بتشغيل الملف الدفعي). لذا فإن أول شيء يكتبه المستخدمون هو activate-py35 ثم تم تكوين PATH بشكل صحيح لـ 3.5. أنا ممزقة للغاية بشأن هذا ، لأنني لا أريد الدخول في موقف vcvarsall.bat ، ولكن في نفس الوقت سيكون الأمر رائعًا للنصوص البرمجية التي تضع حاليًا افتراضات حول مواقع التثبيت أو تحاول الانتقال من خلال التسجيل للعثور عليه.

وربما اختصارًا يقوم بتشغيل الملف الدفعي

في رأيي ، هذا هو اختصار موجه الأوامر "Python 3.5 (32 بت)". يجب على مستخدمي Visual Studio التعرف على التوازي.

لا أعرف ما يكفي عن Windows لفهم الآثار المترتبة على كل ذلك تمامًا ، لكنني أشعر بالسوء حيال العودة إلى حالة لا يمكن فيها تثبيت برنامج نصي $ # pip install foo foo على الفور تم تنفيذه كـ foo في سطر الأوامر. إذا كنا نقوم بالتثبيت على --user ولم يكن ذلك على مسارهم بشكل افتراضي ، فهذا يبدو وكأنه تراجع كبير بالنسبة لي.

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

بالنسبة لتكوين PATH على Windows ، سيكون ذلك مستحيلًا تقريبًا. يمكن للمثبت على مستوى النظام تكوين متغيرات البيئة على مستوى النظام فقط ولا يمكن أن تتضمن توسعات ، لذلك لا يمكنك تعيين مسارات مختلفة لكل مستخدم.

أوه ، مقرف. لقد نسيت ذلك.

وربما اختصارًا يقوم بتشغيل الملف الدفعي
في رأيي ، هذا هو اختصار موجه الأوامر "Python 3.5 (32 بت)". يجب على مستخدمي Visual Studio التعرف على التوازي.

... وهو أمر مروع لأولئك منا الذين يتخلفون عن استخدام Powershell في كل شيء.

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

متفق. سيكون هذا تراجعا سيئا ويحتاج إلى معالجة. أتمنى فقط أن يفكر شخص ما في طريقة :-)

لست متأكدًا من أنني أفهم بالضبط كيف سيعمل استخدام py.exe للبرامج النصية غير المنسوخة عمليًا

أعتقد أن النقطة (التي تتعلق إلى حد ما فقط بـ py.exe ) هي أن غلاف exe ، بدلاً من استدعاء مترجم Python محدد الشفرة كما هو الحال حاليًا ، يجب أن يختار المترجم بشكل ديناميكي بناءً على "ماذا هو الافتراضي "بطريقة ما (ريجستري ، ملف py.exe ini ، أيا كان Python٪ PATH٪ ، ...). لست متأكدًا من كيف سيساعد ذلك ، لأننا ما زلنا بحاجة إلى دليل البرامج النصية للمستخدم (لتجنب الملفات التي تحل محل بعضها البعض أو يتم تشغيل الملفات مع المترجمين الفوريين الذين لم يتم تثبيت الحزمة) وما زلنا لا يمكنني وضع ذلك في النقطة الصحيحة في٪ PATH٪.

... وهو أمر مروع لأولئك منا الذين يتخلفون عن استخدام Powershell في كل شيء.

لقد جربته للتو ، ويمكنني بسهولة إنشاء ملفات activate-py35.bat و activate-py35.ps1 تبدو وتتصرف بشكل متماثل (على سبيل المثال ، يجب على الجميع كتابة activate-py35 وتحديث المسارات). لا يزال ليس مثاليًا ، ولكن ربما يكون أفضل حالة سيئة.

لست متأكدًا من أنني أفهم بالضبط كيف سيعمل استخدام py.exe للبرامج النصية غير المنسوخة عمليًا

أعتقد أن النقطة (التي تتعلق إلى حد ما فقط بـ py.exe ) هي أن غلاف exe ، بدلاً من استدعاء مترجم Python الشفهي المحدد ، كما هو الحال في الوقت الحالي ، يجب أن يختار المترجم بشكل ديناميكي بناءً على "ماذا هو الافتراضي "بطريقة ما

"بطريقة ما" هو المكان الذي يأتي فيه py.exe - يجب استخدام نفس القواعد. إذا تم تحديث المشغل للتحقق من اسمه ، فبدلاً من إطلاق python.exe ، يمكن أن يحاول إطلاق 'scripts\\{}{}.{}.exe'.format(argv[0], major_version, minor_version) (بامتداد مناسب للقطع على argv[0] ، إلخ) بدلاً من ذلك. بعد ذلك ، يحتاج المثبتون إلى استخدام ملف مختلف لمشغل الإصدار غير المحرر من الإصدار الكامل (والذي لن يتغير من اليوم) ، ولكن هذا الملف سيكون فقط py.exe العادي مع اسم جديد. (كان من الممكن أن يكون هذا أبسط في الأيام الخوالي لملفات pip-script.py ، لكن الآن بعد أن اختفت هذه الملفات ...)

ولكن كما قلت ، لا يزال PATH هو المشكلة. ليس لدي أي حلول جيدة ، ولا حتى الكثير من الحلول السيئة. متغيرات البيئة مخصصة حقًا للمسؤولين أو المستخدمين للتهيئة ، وليس للمثبِّتين.

يمكننا تعديل كيفية تثبيت البرامج النصية لتقديم تجربة مستخدم أفضل. كل شيء رصيد ، الملف المدمج .exe و .py جعل الأشياء أكثر جمالًا للمستخدمين نظرًا لوجود الملف الوحيد .exe . ومع ذلك ، أشعر أن الحصول على أفضل قصة مقابل pip install foo && foo أكثر أهمية من ذلك الشيء المحدد ، لذلك إذا احتجنا إلى فصل .exe و .py مرة أخرى ، أعتقد أن هذا هو مقايضة جيدة للحصول على إجابة جيدة.

الفصل .exe / .py هو أقل المشاكل :)

أنا في الواقع أحضر (أو أقبل على مضض؟) فكرة activate-py35 . لم أكن أبدًا من المعجبين ببرنامج التثبيت الذي أضاف Python إلى PATH على الإطلاق ، ولم يكتسب الأمر py -m pip قوة دفع (ولن يعمل ، على سبيل المثال ، Sphinx). سأكتب وصفًا أكثر تفصيلاً لكيفية عمل activate-py وأرسله إلى python-dev لمعرفة ما إذا كان سيحصل على أي تأثير.

هل ستكون هذه الملفات activate-whatever مماثلة لتلك الموجودة داخل البيئة الافتراضية؟ باستثناء أنه بدلاً من إضافة بيئة افتراضية إلى $PATH ، يتم إضافة Pythons الحقيقية؟

نعم ، متطابق إلى حد كبير. في python-dev ، اقترحت للتو أنهم سيأخذون المعلمة -x.y ، ثم مررها إلى py.exe واستخدم sysconfig للحصول على المسارات.

نعم. ليس لدي رأي حول مدى ضرر ذلك لمستخدمي Windows لأنني لست واحدًا. لا يبدو الأمر مروعًا تمامًا (ربما؟) ولكن هذا بقدر ما يمكن أن تأخذني معرفتي بنظام Windows.

في 10 فبراير 2015 ، في الساعة 08:02 صباحًا ، كتب دونالد ستافت:

أوه ، والشيء الضرب بالبرنامج النصي هو مشكلة عامة ليست كذلك
مرتبطة حقًا بـ --user تمامًا. نفس المشكلة موجودة في كل مكان
باستثناء تثبيتات Windows --global . أعتقد أن الحل لهذه المشكلة هو
مشكلة / مشكلة ثانوية يجب حلها بشكل منفصل لهذه المشكلة.

متفق.

سنستخدم العلم --global .

+1

من المحتمل أننا نريد نوعًا من التحذير إذا كنا نقوم بالتثبيت في --user و
~/.local/bin ليس موجودًا في $PATH .

+1 ، ربما مع خيار التكوين لمنع التحذير؟

سنريد نوعًا من الخيار default-install الذي سيكون بشكل أساسي
تعطيل السلوك الاحتياطي وفقط الرمز الثابت إما --global أو
--user .

+1

اعتبارًا من النقطة 6.0 ، لدينا ملفات تكوين خاصة بالجهاز موجودة في /etc/
لكن هذه ليست خاصة بإصدار Python الذي يتم تنفيذه
نقطة. أعتقد أن هذه ميزة جيدة رغم أنها منفصلة إلى حد ما أيضًا (و
قد يسير جنبًا إلى جنب مع حل أمر الضرب النصي أيضًا).

أود أن أقترح طلب بحث مثل:

• pipX.Y.conf
• pipX.conf
• نقطة

متجذر أولاً (؟) في / etc / xdg / pip ثم / etc ، حيث XY بالطبع هو
رقم الإصدار الرئيسي. أول واحد وجد ، يفوز.

لا يزال هناك سؤال مفتوح رئيسي واحد: على المدى الطويل ، ماذا نريد أن يحدث ومتى
شخص ما يفعل sudo pip install foo أو بالأحرى ، إذا كان لدى شخص الإذن بذلك
الكتابة إلى الدليل site-packages ؟

يرجى ملاحظة أنه لا يوجد دليل "حزم مواقع" واحد فقط. علي سبيل المثال،
على Debian / Ubuntu ، لا نريد تثبيت sudo pip install على الإطلاق
/ usr / lib ، لكن فقط / usr / local / lib. ولا تنسى ، إنها حزم توزيع هنا
ليس حزم المواقع (باستثناء ~ / .local لأن $ أسباب).

هذه حقًا نقطة مهمة يتم نسيانها أحيانًا (حتى من قبلي).
يصف دونالد ذلك بشكل أفضل عندما يقول أن هناك دليلًا محليًا للموقع وملف
دليل البائع المحلي. على ديبيان ، site-local هو
/usr/lib/pythonX.Y/dist-packages ولا يجب أن يلمس ذلك أي أمر pip ،
بينما البائع المحلي هو /usr/local/lib/pythonX.Y/dist-packages وهو
حالة استخدام موثقة وشائعة لبعض مسؤولي النظام لتثبيتها
في هذا الدليل.

لذا فإن ما أقترحه ، نظرًا لأننا بالفعل أسفل مسار ملف التكوين ، هو
اجعلها قابلة للتكوين ، على سبيل المثال

• دليل_التثبيت_العالمي
• global_install_as_sudo (صح / خطأ)

1. التثبيت في --global . هذا هو الخيار الأكثر توافقًا مع الإصدارات السابقة
   ويمثل على الأرجح ما يتوقعه المستخدمون عند كتابة ذلك. ومع ذلك فقد
   الجانب السلبي أنه سوف يعبث (بصمت) مع Python العالمية ، والتي على الكثيرين
   يمكن أن تتسبب الأنظمة في تعطل الأنظمة.

مع قابلية التكوين المذكورة أعلاه ، سيكون هذا متوافقًا تمامًا مع دبيان.
يتوقع مستخدمو دبيان المتميزون استخدام sudo pip install
/usr/local/lib/pythonX.Y/dist-packages. لن أقول ذلك "عبث مع
system "لأنه لا يكسر مدير الحزم ، وبينما يمكنه ذلك
تجاوز حزم النظام المثبتة (التي تعيش في
/usr/lib/pythonX.Y/dist-packages) ، يفعل ذلك بطريقة محددة وموثقة.

1. قم بالتثبيت في --user ، فهذا سيحمي من الأنظمة المعطلة (أعتقد؟)
   لكن لا أعتقد أن أي شخص يتوقع أن يحصل المستخدم الجذر على ملف
   تثبيت /root/.local/ .

متفق عليه ، سيكون ذلك غير متوقع.

1. فقط حدث خطأ واطلب من المستخدم تحديد إما --user أو
   --global يدويًا.

سأكون على ما يرام مع ذلك ، لكن انظر إلى مفتاح التكوين أعلاه.

1. اختر أحد الخيارين الأولين ، ولكن وفر مفتاحًا تستطيع التوزيعات القيام به
   بدوره في /etc/ الذي سيمكن الخيار الثالث.

مرحبًا ، يا له من خيار رائع!

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

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

أشعر أن الخيار الثالث سيئ على الأرجح ، لأنني "لقد كتبت
إذن "سيكون هو السيناريو الذي يكون فيه أي شخص على Windows قيد التشغيل المسبق
Python 3.5 ، أو أي شخص يستخدم Conda ، أو أي شخص يستخدم Pyenv. خطأ في الخروج
يبدو أنه الشيء الخطأ الذي يجب فعله في كل تلك الحالات وهو كذلك أي مستخدم
غير ودي للتمهيد.

سأكون سعيدًا إذا كان التكوين الافتراضي هو السماح بالتثبيت العالمي إذا كنت
لدى اذن. لا أعتقد حتى أن دبيان ستغيرها (ربما فعلها الآخرون
رأي مختلف ، ولكن على الأقل هذا يعطينا خيارات).

لذا أعتقد أن ما بين 1 و 2 يرجع حقًا إلى مدى سوء الممارسة
نعتقد أنه يجب على الأشخاص (من الناحية النظرية) القيام بـ sudo pip install --global foo .

في دبيان ، إنها حالة استخدام متوقعة ، طالما أنها تنتقل إلى / usr / local / lib.
لا يمكن الذهاب إلى / usr / lib.

(كل هذا يصف السلوك الخارجي راجع للشغل.)

• عندما يتم تمرير --user نقوم دائمًا بالتثبيت في حزم موقع المستخدم.

+1

• عندما يتم تمرير --global نقوم دائمًا بالتثبيت في الموقع العالمي
• الحزم.

حزم _vendor_ العالمية == +1 ، حزم الموقع العالمية == -1.

• عندما لا يتم تمرير أي منهما ، فإننا نطبق طريقة احتياطية والتي:
  
  
  
  1. يكتشف ما إذا كنا في بيئة افتراضية وإذا كان الأمر كذلك يتصرف كما لو
     
     تم تجاوز --global .
  
  

+1 ، على الرغم من أنني سأكرر هذا الدليل داخل ملف venv
/lib/pythonX.Y/site-packages

1. يكتشف ما إذا كانت حزم مواقع المستخدم معطلة وإذا كان الأمر كذلك يتصرف كما لو
   تم تجاوز --global .

حسنًا ، لست متأكدًا من هذا.

1. ينظر إلى default-install وإذا كان موجودًا يستخدم --user أو
   -global بناءً عليه.

+1

1. يكتشف ما إذا كان المستخدم الفعال ليس لديه أذونات الكتابة إلى العمومية
   حزم الموقع ، وإذا كانت لا تتصرف كما لو تم تمرير --user .

+1

1. أخيرًا ، إذا فشلت جميع طرق الكشف الأخرى ، فتصرف كما لو كان --global
   تم تمريره.

أيضا غير متأكد.

هذا يعني عدم وجود فترة إهلاك وأن التوقع هو ذلك في
غياب --user أو --global سنحاول أن نبني أفضل تخمين
حول إمكانيات Python التي نستخدمها ، والمستخدم الفعال ، و
أي طريقة تثبيت افتراضية تم تكوينها.

يبدو وكأنه هدف معقول.

لكي أكون واضحًا ، عندما أتحدث عن "حزم المواقع العالمية" ، فأنا أعني في المقام الأول "أيًا كانت المقطوعات تخبرنا بتثبيت الأشياء على مستوى عالمي". نظرًا لأن Python نفسها لا تحتوي على تمييز "البائع المحلي" مقابل "الموقع المحلي" ، فسيكون هذا هو نفس الدليل على أي اتجاه لا يعمل على تصحيح Python. في دبيان ، سيكون في الواقع دليل dist-packages بينما تعني كلمة "global" في الواقع "موقع محلي". هذا ليس شيئًا يحتاج Pip إلى القيام بأي شيء خاص لدعمه على الرغم من أنه يتم الاهتمام به من خلال تصحيحات Debuntu إلى Python.

بمعنى آخر ، يتم تثبيت النقطة بالفعل على /usr/local/../dist-packages/ على Debuntu نظرًا لأن Debuntu قد قام بتصحيح التوزيعات لدعم هذا التمييز. الوقت الوحيد الذي يمكن أن يعبث فيه النقطة بـ /usr/../dist-packages/ دون أن يمر المستخدم بعلامة من نوع ما هو أن النقطة سوف تقوم بإلغاء تثبيت الملفات من هناك (لأن النقطة لا ترى هذا الدليل على أنه دليل خاص ، فإنه يراه فقط كشيء على sys.path ). قامت دبيان بتصحيح النقطة لمنع هذا الإزالة من هناك ، وأعتقد أن الدعم الحقيقي لذلك يعتمد على الحصول على دعم حقيقي لحزم موقع "البائع المحلي" في Python upstream.

من المحتمل أننا نريد نوعًا من التحذير إذا كنا نقوم بالتثبيت في --user و ~ / .local / bin ليس على المسار $

ما مدى هشاشة هذا التحذير على الأرجح؟ هل سيتحول إلى المسار المطلق؟ هل سيكون غير حساس لحالة الأحرف على أنظمة الملفات غير الحساسة لحالة الأحرف؟ هل سيعامل و / كمكافئ على Windows؟ ماذا عن الروابط الرمزية؟

إذا كنت تقوم بتثبيت حزمة لا تقوم بتثبيت أي برامج نصية ، فإن التحذير غير ذي صلة على أي حال.

أنا شخصياً أعتقد أن التحذير من المحتمل أن يضر أكثر مما ينفع.

من المحتمل أننا نريد نوعًا من التحذير إذا كنا نقوم بالتثبيت في --user و
~/.local/bin ليس موجودًا في $PATH .

+1 ، ربما مع خيار التكوين لمنع التحذير؟

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

اعتبارًا من النقطة 6.0 ، لدينا ملفات تكوين خاصة بالجهاز موجودة في /etc/
لكن هذه ليست خاصة بإصدار Python الذي يتم تنفيذه
نقطة. أعتقد أن هذه ميزة جيدة رغم أنها منفصلة إلى حد ما أيضًا (و
قد يسير جنبًا إلى جنب مع حل أمر الضرب النصي أيضًا).

أود أن أقترح طلب بحث مثل:

• pipX.Y.conf
• pipX.conf
• نقطة

متجذر أولاً (؟) في / etc / xdg / pip ثم / etc ، حيث XY بالطبع هو
رقم الإصدار الرئيسي. أول واحد وجد ، يفوز.

قسّم هذا إلى # 2417 لأنني أعتقد أنه مرتبط بشكل ملموس بهذا فقط
نقاش.

لا يزال هناك سؤال مفتوح رئيسي واحد: على المدى الطويل ، ماذا نريد أن يحدث ومتى
شخص ما يفعل sudo pip install foo أو بالأحرى ، إذا كان لدى شخص الإذن بذلك
الكتابة إلى الدليل site-packages ؟

يرجى ملاحظة أنه لا يوجد دليل "حزم مواقع" واحد فقط. علي سبيل المثال،
على Debian / Ubuntu ، لا نريد تثبيت sudo pip install على الإطلاق
/ usr / lib ، لكن فقط / usr / local / lib. ولا تنسى ، إنها حزم توزيع هنا
ليس حزم المواقع (باستثناء ~ / .local لأن $ أسباب).

هذه حقًا نقطة مهمة يتم نسيانها أحيانًا (حتى من قبلي).
يصف دونالد ذلك بشكل أفضل عندما يقول أن هناك دليلًا محليًا للموقع وملف
دليل البائع المحلي. على ديبيان ، site-local هو
/usr/lib/pythonX.Y/dist-packages ولا يجب أن يلمس ذلك أي أمر pip ،
بينما البائع المحلي هو /usr/local/lib/pythonX.Y/dist-packages وهو
حالة استخدام موثقة وشائعة لبعض مسؤولي النظام لتثبيتها
في هذا الدليل.

لذا فإن ما أقترحه ، نظرًا لأننا بالفعل أسفل مسار ملف التكوين ، هو
اجعلها قابلة للتكوين ، على سبيل المثال

• دليل_التثبيت_العالمي
• global_install_as_sudo (صح / خطأ)

لا تتحكم النقطة فعليًا في هذه (أعني ، من الواضح أنها تتمتع بمستوى عالٍ
لأنها هي التي تنقل الملفات) ، فهي تأتي من distutils / sysconfig.

أعتقد أنه من المحتمل ألا تلمس النقطة دليل البائع المحلي إلا إذا
تم إعطاء نوع من العلم مثل --vendor والذي سيمكن البائعين من استخدام
نقطة في سلسلة البناء الخاصة بهم. هذا المفهوم غير موجود حقًا خارج debuntu
الآن وبقعهم تتعامل مع هذا بالفعل ، لذلك لا أعتقد أنه رائع
ذات الصلة بهذه المناقشة إلا أن أشير إلى ذلك عندما أقول
"حزم الموقع العالمية" قصدت /usr/local/.../dist-packages على Debubuntu
وحزم "site-local" في مرحلة ما إذا قبلت Python Debuntu
نظام المنبع.

1. التثبيت في --global . هذا هو الخيار الأكثر توافقًا مع الإصدارات السابقة
   ويمثل على الأرجح ما يتوقعه المستخدمون عند كتابة ذلك. ومع ذلك فقد
   الجانب السلبي أنه سوف يعبث (بصمت) مع Python العالمية ، والتي على الكثيرين
   يمكن أن تتسبب الأنظمة في تعطل الأنظمة.

مع قابلية التكوين المذكورة أعلاه ، سيكون هذا متوافقًا تمامًا مع دبيان.
يتوقع مستخدمو دبيان المتميزون استخدام sudo pip install
/usr/local/lib/pythonX.Y/dist-packages. لن أقول ذلك "عبث مع
system "لأنه لا يكسر مدير الحزم ، وبينما يمكنه ذلك
تجاوز حزم النظام المثبتة (التي تعيش في
/usr/lib/pythonX.Y/dist-packages) ، يفعل ذلك بطريقة محددة وموثقة.

نعم ، قد تكون "العبث بالنظام" قاسية جدًا. في الغالب أعني ذلك
sudo pip install foo قد يكسر الأشياء إذا كان النظام يعتمد على foo و
تقوم بتثبيت إصدار غير متوافق من الأشياء. ومع ذلك فإن نفس الحالة تنطبق
صحيح بالنسبة لأي شيء تقوم بتثبيته في `/ usr / local ''.

• عندما يتم تمرير --global نقوم دائمًا بالتثبيت في الموقع العالمي
• الحزم.

حزم _vendor_ العالمية == +1 ، حزم الموقع العالمية == -1.

تقصد هذا في الاتجاه المعاكس ، أليس كذلك؟

• عندما لا يتم تمرير أي منهما ، فإننا نطبق طريقة احتياطية والتي:
  
  
  
  1. يكتشف ما إذا كنا في بيئة افتراضية وإذا كان الأمر كذلك يتصرف كما لو
     
     تم تجاوز --global .
  
  

+1 ، على الرغم من أنني سأكرر هذا الدليل داخل ملف venv
/lib/pythonX.Y/site-packages

نعم ، مرة أخرى نسأل Python عن مكان هذا الدليل ، ولا نحسبه
أنفسنا ، لذا فإن "حيث يوجد هذا الدليل" هو شيء venv / virtualenv.

1. يكتشف ما إذا كانت حزم مواقع المستخدم معطلة وإذا كان الأمر كذلك يتصرف كما لو
   تم تجاوز --global .

حسنًا ، لست متأكدًا من هذا.

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

1. أخيرًا ، إذا فشلت جميع طرق الكشف الأخرى ، فتصرف كما لو كان --global
   تم تمريره.

أيضا غير متأكد.

يتلخص هذا في الأساس في:

إذا لم نعثر على سبب ، فيجب علينا استخدام --user ، مثل --user flag ، أو
ليس لديك أذونات للكتابة إلى الدليل ، ثم لا تستخدمها. هذه
هو ما سيبقي sudo pip install foo بدون علم --global
عمل. هذا يعني أيضًا أن هذه هي القاعدة الأكثر أهمية لعدم كسرها
برنامج العمل الذي يتوقع sudo pip install foo أن يتصرف بهذه الطريقة.

من المحتمل أننا نريد نوعًا من التحذير إذا كنا نقوم بالتثبيت في --user و ~ / .local / bin ليس على المسار $

ما مدى هشاشة هذا التحذير على الأرجح؟ هل سيتحول إلى المسار المطلق؟ هل سيكون غير حساس لحالة الأحرف على أنظمة الملفات غير الحساسة لحالة الأحرف؟ هل سيعامل و / كمكافئ على Windows؟ ماذا عن الروابط الرمزية؟

إذا كنت تقوم بتثبيت حزمة لا تقوم بتثبيت أي برامج نصية ، فإن التحذير غير ذي صلة على أي حال.

أنا شخصياً أعتقد أن التحذير من المحتمل أن يضر أكثر مما ينفع.

حسنًا ، يمكننا تنفيذه باعتباره (مكافئ عبر النظام الأساسي):

def user_bin_on_path():
    paths = os.environ.get("PATH").split(":")
    for path in paths:
        if os.path.realpath(path) == os.path.realpath(USER_BIN_DIR):
            return True
    return False

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

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

الفكرة الأساسية هي أنني لا أريد أن يقوم شخص ما بشيء مثل pip install [--user] foo حيث يكون المستخدم - ضمنًا ، ثم تنفيذ foo والحصول على "أمر غير موجود" بدون أي إرشادات حول لماذا قد لا يتم العثور عليها. سيخبرهم التحذير على الأقل أنهم بحاجة إلى إضافة أشياء إلى المسار. قد يساعد أيضًا في مطالبة المستخدمين على Windows بإضافة دليل المستخدم الخاص بهم إلى PATH يدويًا (أو تشغيل بعض البرامج النصية للقيام بذلك) مما قد يخفف من الحاجة إلى البرامج النصية activate التي أشار إليها ستيف. على الرغم من أنني أعتقد أن هذا لا يزال يعني أن قيم النظام لها الأسبقية على قيم المستخدم بحيث لا يزال ذلك محيرًا نظرًا لأن ترتيب PATH و sys.path لا يزال يتم عكسه.

دوه. لقد نسيت أن realpath جعل المسار متعارف عليه. نعم ، بالطبع هذا يعمل بشكل جيد بما فيه الكفاية.

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

حسنًا ، أعتقد أن لدينا اتفاقًا واسعًا هنا. أعتقد أن الخطوة التالية هي الحصول على تصحيح. سأذهب وأحاول الحصول على شيء في وقت لاحق الليلة أو غدا.

في 10 شباط (فبراير) 2015 ، الساعة 12:14 ظهرًا ، كتب دونالد ستافت:

الفكرة الأساسية هي أنني لا أريد أن يفعل شخص ما شيئًا مثل pip install [--user] foo حيث يكون المستخدم - ضمنًا ، ثم يفعل foo و
الحصول على "أمر غير موجود" بدون أي إرشادات حول سبب عدم وجوده
وجدت.

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

٪ إنكسكيب
برنامج "inkscape" غير مثبت حاليًا. يمكنك تثبيته عن طريق كتابة:
sudo apt-get install inkscape

ربما يمكننا ربط ذلك بالمنصات الداعمة.

في 10 فبراير 2015 ، في الساعة 12:06 مساءً ، كتب دونالد ستافت:

• عندما يتم تمرير --global نقوم دائمًا بالتثبيت في الموقع العالمي
• الحزم.

حزم _vendor_ العالمية == +1 ، حزم الموقع العالمية == -1.

تقصد هذا في الاتجاه المعاكس ، أليس كذلك؟

يمكنني خلط المصطلحات الخاصة بي ، لذلك سأكون صريحًا:

/usr/local/lib/pythonX.Y/dist-packages == +1
/usr/lib/pythonX.Y/dist-packages == -1

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

1. يكتشف ما إذا كانت حزم مواقع المستخدم معطلة وإذا كان الأمر كذلك يتصرف كما لو
   تم تجاوز --global .

حسنًا ، لست متأكدًا من هذا.

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

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

1. أخيرًا ، إذا فشلت جميع طرق الكشف الأخرى ، فتصرف كما لو كان --global
   تم تمريره.

أيضا غير متأكد.

يتلخص هذا في الأساس في:

إذا لم نعثر على سبب ، فيجب علينا استخدام --user ، مثل --user flag ، أو
ليس لديك أذونات للكتابة إلى الدليل ، ثم لا تستخدمها. هذه
هو ما سيبقي sudo pip install foo بدون علم --global
عمل. هذا يعني أيضًا أن هذه هي القاعدة الأكثر أهمية لعدم كسرها
برنامج العمل الذي يتوقع sudo pip install foo أن يتصرف بهذه الطريقة.

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

normal_user $ pip install foo
مرحبًا ، ليس لديك أذونات
normal_user $ sudo pip install foo
مرحبًا ، لقد وفرت نظامك للتو

و "عدم وجود أذونات للكتابة إلى الدليل يشير إلى قاعدة --user"
يعتني بذلك.

أوه نعم لقد نسيت أمر غير موجود. يمكن أن يكون مفيدا. بالمناسبة ، هل تعرف المكان المناسب لاقتراح أن devubtu لديه الصندوق المحلي للمستخدم على المسار افتراضيًا؟

في 10 فبراير 2015 ، في تمام الساعة 4:05 مساءً ، كتب Barry Warsaw [email protected] :

في 10 شباط (فبراير) 2015 ، الساعة 12:14 ظهرًا ، كتب دونالد ستافت:

الفكرة الأساسية هي أنني لا أريد أن يفعل شخص ما شيئًا مثل pip install [--user] foo حيث يكون المستخدم - ضمنًا ، ثم يفعل foo و
الحصول على "أمر غير موجود" بدون أي إرشادات حول سبب عدم وجوده
وجدت.

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

٪ إنكسكيب
برنامج "inkscape" غير مثبت حاليًا. يمكنك تثبيته عن طريق كتابة:
sudo apt-get install inkscape

ربما يمكننا ربط ذلك بالمنصات الداعمة.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

في 10 فبراير 2015 ، في تمام الساعة 01:17 مساءً ، كتب دونالد ستافت:

أوه نعم لقد نسيت أمر غير موجود. يمكن أن يكون مفيدا. بالمناسبة هل أنت
تعرف على المكان المناسب لاقتراح أن devubtu لديه حاوية محلية للمستخدم على
المسار بشكل افتراضي؟

ليس نهائيا ، ولكن ربما الحزم adduser أو passwd؟ السابق يملك
/ usr / sbin / adduser والأخير يمتلك / usr / bin / useradd.

أول تمرير: https://github.com/pypa/pip/pull/2418

لست متأكدًا مما إذا كان هذا يساعد ، ولكن ...

• ~ / .local / bin ليس في العديد من الأشخاص $ PATH ، فهل هناك أي شيء يمكن القيام به حيال ذلك؟

تستخدم بعض المشاريع الأخرى /etc/profiled.d/ لإضافة الدلائل إلى $ PATH. على الأقل في Antergos أرى ما يلي (ما لم أساء فهم ما تفعله هذه) jre.csh و jre.sh و perlbin.csh و perlbin.sh.

# Do not change this unless you want to completely by-pass Arch Linux' way
# of handling Java versions and vendors. Instead, please use script `archlinux-java`
setenv PATH "${PATH}:/usr/lib/jvm/default/bin"

# Do not change this unless you want to completely by-pass Arch Linux' way
# of handling Java versions and vendors. Instead, please use script `archlinux-java`
export PATH=${PATH}:/usr/lib/jvm/default/bin

# Set path to perl scriptdirs if they exist
# https://wiki.archlinux.org/index.php/Perl_Policy#Binaries_and_Scripts
# Added /usr/bin/*_perl dirs for scripts
# Remove /usr/lib/perl5/*_perl/bin in next release

[ -d /usr/bin/site_perl ] && setenv PATH ${PATH}:/usr/bin/site_perl
[ -d /usr/lib/perl5/site_perl/bin ] && setenv PATH ${PATH}:/usr/lib/perl5/site_perl/bin

[ -d /usr/bin/vendor_perl ] && setenv PATH ${PATH}:/usr/bin/vendor_perl
[ -d /usr/lib/perl5/vendor_perl/bin ] && setenv PATH ${PATH}:/usr/lib/perl5/vendor_perl/bin

[ -d /usr/bin/core_perl ] && setenv PATH ${PATH}:/usr/bin/core_perl

# If you have modules in non-standard directories you can add them here.
#export PERLLIB=dir1:dir2

# Set path to perl scriptdirs if they exist
# https://wiki.archlinux.org/index.php/Perl_Policy#Binaries_and_Scripts
# Added /usr/bin/*_perl dirs for scripts
# Remove /usr/lib/perl5/*_perl/bin in next release

[ -d /usr/bin/site_perl ] && PATH=$PATH:/usr/bin/site_perl
[ -d /usr/lib/perl5/site_perl/bin ] && PATH=$PATH:/usr/lib/perl5/site_perl/bin

[ -d /usr/bin/vendor_perl ] && PATH=$PATH:/usr/bin/vendor_perl
[ -d /usr/lib/perl5/vendor_perl/bin ] && PATH=$PATH:/usr/lib/perl5/vendor_perl/bin

[ -d /usr/bin/core_perl ] && PATH=$PATH:/usr/bin/core_perl

export PATH

# If you have modules in non-standard directories you can add them here.
#export PERLLIB=dir1:dir2

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

كجانب جانبي ، أستخدم Homebrew وأقدر دائمًا حقيقة أنه يمكنني فقط brew install something وسيعمل دون أي ضجة حول الأذونات.

بمجرد أن فهمت لماذا لم يتطلب التثبيت مع Homebrew أبدًا sudo ، حاولت التعود على القيام ب pip install --user something ، لكن من المفارقات أن Homebrew يعطل هذا بسبب خطأ تم الإبلاغ عنه في Distutils.

نظرًا لشعبية Homebrew على OS X ، فربما ترغبون في النظر في هذا التعارض المزعوم لـ Homebrew و pip install --user .

على أي حال ، +1 مني عند جعل --user هو الخيار الافتراضي.

متابعة سريعة. قام ديدييه بتحميل تغيير على نقطة Ubuntu بشكل حي جعل المستخدم افتراضيًا. لقد سمحت بذلك أيضًا في الغالب ولكن الآن أعتقد أنه كان خطأ وأعتزم التراجع عن ذلك لمكر (ولكن ربما لن يكون تغيير SRU واضحًا). راجع https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1460203 للحصول على التفاصيل والأساس المنطقي.

+1 لترك توقيت هذا التغيير لأعلى ، حيث أن التمييز بين المستخدم والنظام هو بالفعل مربك بدرجة كافية دون ظهور اختلافات في النظام الأساسي.

بعد قولي هذا ، قد يكون من المعقول أن تبدأ توزيعات Linux في قلب الافتراضي إلى - المستخدم بمجرد أن يصل الدعم العالمي إلى نقطة أعلى (النقطة 8؟) ، منذ إجراء عمليات التثبيت العالمية على Linux ، بدلاً من كل مستخدم أو تثبيتات per-venv ، تعتبر فكرة سيئة لها آثار جانبية غير متوقعة.

لقد أخبرت warsaw بشكل خاص ، لكنني سأقولها هنا أيضًا:

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

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

ربما يستحق التكرار في هذه المرحلة:

إذا انتهى بنا الأمر إلى اتخاذ قرار ضد "التقصير إلى - المستخدم" ، فيجب علينا التفكير في البدائل الأقل اضطرابًا

1. الرجوع إلى المستخدم (في حالة فشل التثبيت بسبب أخطاء الإحاطة)
2. (إذا فشل التثبيت بسبب أخطاء محيطية) ، شجع المستخدم (بأحرف كبيرة ودية) لمحاولة --user

FWIW ، الآن بعد أن شجع مثبت Windows لـ Python 3.5 بشدة التثبيت لكل مستخدم ، لست قلقًا بشأن حدوث هذا التغيير في نقطة. من المحتمل أن يكون خيار تكوين أفضل للتوزيعات (مع تجاوز --global ) من خيار افتراضي جديد أو احتياطي.

أردت فقط الدخول لإجراء 1+ لهذه المشكلة والتعبير عن شكرك للعمل على هذه المشكلة! نحن ندير مدرسة صيفية علمية بلغة Python حاليًا ولدينا العديد من الأشخاص sudo pip install عندما واجهوا مشكلات تتعلق بالأذونات.

FWIW أنا أؤيد التخلف عن السداد إلى --user ، أو الرجوع إلى --user إذا فشل التثبيت بسبب أخطاء الأذونات. في هذه الحالة ، أفضل أن أعطيهم التوجيهات لعكس ما فعلوه (على سبيل المثال ، We installed to your user directory. If you don't want this, then 'pip uninstall my_package' ) بدلاً من الفشل وإخبارهم بكيفية المحاولة مرة أخرى.

أرى الكثير من تقارير الأخطاء عن mock بسبب --user - على الأقل في Ubuntu حيث - يكون مكان المستخدم على المسار بعد حزم التوزيع ، وبالتالي لم يتم استخدام النقطة المثبتة فعليًا ، لأي تبعية مشتركة (مثل ستة) التي هي في توزيعات الحزم.

وضعوه _after_ dist-packages ؟ هذا تثبيت معطل IMO.

صحيح ، يجب أن تكون عمليات تثبيت المستخدم قبل حزم site (/ dist) ، ثم يجب تشغيل البرامج النصية والأدوات المساعدة للنظام مع -I (أو -Es في Python 2).

نعم اوافق :). قد يتم إصلاحه بشكل واضح ، لكنني بالتأكيد يبدو أني أبلغ عن مصدر الأشياء من المكان الخطأ تمامًا.

لقد استخدمت للتو نقطة النظام لتثبيت أدوات الإعداد على جهازي النابض بالحياة للتجربة.

>>> import setuptools
>>> setuptools.__path__
['/home/robertc/.local/lib/python2.7/site-packages/setuptools']
>>> import sys
>>> sys.path
['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/home/robertc/.local/lib/python2.7/site-packages', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PILcompat', '/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/pymodules/python2.7', '/home/robertc/work/mock']

لذلك هذا الشخص عاقل. ولكن من المربك أن هذا تم تقديمه بشكل واضح - لذا IDK. سأرى ما إذا كان بإمكاني البحث عن ناسخ في مرحلة ما (لتقديمه في Ubuntu BTS)

الاستدعاء warsaw

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

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

إنه "حل سريع" لطيف للمشكلة حتى ننتقل فعليًا إلى التقصير إلى --user .

مطلوب أيضًا - عالمي أو - نظام أو - لا مستخدم في حالة تعيين وضع المستخدم في /etc/pip.conf. لا توجد طريقة سهلة للمستخدمين لتجاوز هذا بقدر ما أستطيع أن أقول.

إنه "حل سريع" لطيف لهذه المشكلة

التحديث المتأخر: # 4233 فعل ذلك.

يجب توجيه الأشخاص (خاصة الوافدين الجدد) الذين لا يستخدمون Windows إلى https://github.com/pyenv/pyenv إذا كانوا يريدون الحصول على تجربة جيدة. لا يبدو PEP 370 منطقيًا بالنسبة لي اليوم ، خاصة وأن ~/.local هو XDG_DATA_HOME.

أعتقد أنني لن أكون الشخص الوحيد الذي سيتخلى عن هذا السلوك إذا / عندما يأتي. آمل أن يكون الانتقال سلسًا ولن أضطر إلى تغيير طريقة عمل نظامي وتمرير إشارات CLI إضافية ، لأنني سعيد جدًا بـ pyenv. بالطبع ، لا أعرف مدى جودة عمل pyenv مع Windows ولكن نظام bash الفرعي يمكن أن يساعد في ذلك ...

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

لن يكون للإعداد الافتراضي --user عند المستوى pip أي تأثير داخل بيئات Python الافتراضية المهيأة بشكل صحيح ، وبالتالي فإن تأثير هذا التغيير على مديري بيئة الطرف الثالث مثل conda و pyenv سيكون pip والأدوات الأخرى (على سبيل المثال الطريقة التي يبلغ بها virtualenv ذلك ، أو طريقة عمل المكتبة القياسية venv ).

الاقتراح ذو الصلة: https://github.com/pypa/pip/issues/1056#issuecomment -218130183.

~ هل تم السماح للمستخدم بتخصيص الدليل (ربما من خلال متغير env) لتجنب التثبيت مباشرة في ~/.local ؟ ربما أفضل دمجهم في ~/.local/pip أو شيء من هذا القبيل - بقدر ما أشعر بالقلق ، لا تتمتع Python بأي حق خاص في المستوى الأعلى من تلك المساحة المشتركة. ~ في 9.0.1 ، يبدو أنه يعشش الأشياء تحت ~/.local/lib/python<version> بالإضافة إلى إضافة الملفات التنفيذية إلى ~/.local/bin والتي أعتقد أنها جيدة ...

jcrben Aye ، الموقع المستهدف هو في الواقع دليل موقع مستخدم Python ، والذي يعكس مخطط التسمية لدليل حزم مواقع النظام: https://docs.python.org/3/library/site.html#site.USER_SITE

هذا قابل للتكوين بالفعل على مستوى المترجم الفوري عن طريق متغير البيئة PYTHONUSERBASE : https://docs.python.org/3/using/cmdline.html#envvar -PYTHONUSERBASE

للمهتمين ، قمت للتو بإصدار https://github.com/ofek/hatch الذي يحتوي على أوامر الحزمة install ، uninstall ، و update التي تكون افتراضية لهذا السلوك. لتعديل النظام ، يمكن للمستخدمين استخدام الخيار -g/--global المماثل لـ https://github.com/npm/npm.

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

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

كخطوة تالية ملموسة ، قمت بنشر مشكلة منفصلة لإضافة علامة --global : https://github.com/pypa/pip/issues/4865

من شبه المؤكد أن هذه فكرة سيئة في بيئات Virtualenv أو conda. أيًا كان ما يتم تثبيته في .local عندما تكون إحدى البيئات نشطة ، يمكن بسهولة كسر بيئة أخرى. إذن ما هو التفكير في تلك الحالات؟

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

لا تنطبق هذه المشكلة عندما تكون داخل بيئة افتراضية نشطة - فهي تنطبق فقط عند عدم اكتشاف بيئة نشطة ، ولم يتم تقديم أي من خيارات تعريف الهدف ( --prefix ، --root ، إلخ) في سطر الأوامر.

كيف يتم تحديد هذا؟

jakirkham https://github.com/ofek/hatch/blob/df2c9d46ee7713a1bc156c361cfd0f78e5935297/hatch/utils.py#L19 -L25

كنا نفكر في تعطيل ~/.local افتراضيًا على sys.path للبيثون داخل بيئات كوندا ، والتي بحكم التعريف تصادف أن تكون أي بيثون مثبتة بواسطة conda. إنه أمر صعب رغم ذلك. في كلتا الحالتين ، قد ينتهي بنا الأمر إلى انتهاك توقعات مجموعة من المستخدمين. مناقشة على https://github.com/conda/conda/issues/7173

لم تكن النقطة قادرة على تحميل أي وسيطة من متغيرات البيئة التي تبدأ بـ PIP_ ؟ هل هذا يعمل مقابل --user ؟ ماذا سيكون اسم المتغير الكامل؟

سيكون ذلك PIP_USER .

محرر المستندات: https://pip.pypa.io/en/stable/user_guide/#environment -variables

PIP_USER=yes على وجه الدقة ، شكرًا! يعد استخدام متغيرات البيئة أسهل بكثير لاستخدام CI حيث يتعين عليك فقط تحديدها مرة واحدة وسيتم استخدامها كلما تم استدعاء الأوامر.

كان علي أن أفعل بعض المنطق القبيح حقًا لـ travis حيث يتم تشغيل بعض المراحل على ما يبدو كمستخدم عادي بدون Virtualemv وبعضها داخل Virtualenv ، وليس لديك فكرة عن أي منها سيكون.

من المحتمل أن يفشل المستخدم داخل virtualenv إذا لم تستخدم حزم الموقع (مما يسبب مشاكل أخرى).

هذه المعلومة التي اضطررت إلى اكتشافها في Virtualenv في bash وتجنب إضافة —user أو run ستفشل.

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

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

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

أي حركة على هذا؟

لم أشاهده مذكورًا ، ولكن ربما يجب أن يشتكي Pip إذا - تم تجاوز المستخدم عند تشغيله تحت sudo.

تؤدي هذه المشكلات التي لم يتم حلها إلى المبرمجين بعيدًا عن pip وحتى لغة python وتجبرهم على استخدام حزم أخرى أو حتى لغات برمجة أخرى مثل javascript و npm مع مشكلات أقل مثل هذه. بالنسبة للمبتدئين الجدد الذين يرغبون في استخدام Python ، فإن هذه الخيارات الإضافية الضرورية محبطة.

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

@ dmikov : إنه ليس الافتراضي. ما لم تكن تستخدم إصدار Debian / Ubuntu المعطل ، في هذه الحالة يمكنك الحل البديل --user الذي يتم تعيينه تلقائيًا باستخدام: PIP_USER=0 pip install -t ... . أو الأفضل من ذلك ، قم بتثبيت إصدار رسمي واستخدامه.

حلمت ليلاً أن يصبح الخيار --user الخيار الافتراضي (لا أمزح) ، هل هناك أي فرصة لتحقيق أحلامي في أي وقت قريبًا؟

أحتاج إلى مساعدة في تثبيت pygame ، فإنه يظل يقول بناء جملة غير صالح

انا إستعملت
تثبيت python3 -m pip -U pygame --user
هل هذا خطأ ماذا افعل؟

@ flamedro56 : بدلاً من التعليق على مشكلة عشوائية ، يرجى فتح واحدة جديدة وتقديم مزيد من المعلومات: إصدار Python ، إصدار النقطة ، نظام التشغيل ، إخراج الأمر ...

ريكابتشا المثبت

ماذا عن وجود خيار تكوين افتراضي جديد = نظام ، مستخدم؟ سيكون من الواضح بما فيه الكفاية أن لا أحد يعتقد أنه يعني "المستخدم دائمًا ، حتى في Virtualenv". سيسمح بمسار هجرة رشيق.

انظر # 4575.

يبدو أن Manjaro يحاول تعيين --user كإعداد افتراضي.

هل هناك أي جديد من المنبع حول هذه المسألة؟

Tids : "filesystem-2018.9-3 يضيف $ HOME / .local / bin إلى $ PATH افتراضيًا." هي القطعة الإضافية الأساسية التي يقوم بها Manjaro بشكل صحيح.

تجمع دبيان بين "افتراضي to --user" على مستوى Python مع "$ HOME / .local / bin ليس في $ PATH افتراضيًا" على مستوى حساب المستخدم ، وهذا هو التحرير والسرد الذي يكسر الأشياء.

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

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

تجدر الإشارة إلى أن خلط عمليات التثبيت من قِبل المستخدم والتثبيتات من غير المستخدمين (للنقطة نفسها) محفوف بالمشكلات - راجع # 7209 كمثال واحد مؤخرًا.

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

(أقوم بإضافة هذا التعليق هنا بشكل أساسي ، لذا يتم تسجيله في مكان ما - إنها في الغالب ليست مشكلة نقطة على الإطلاق ، بل هي تعقيد لكيفية عمل دليل USER_SITE في Python بشكل عام ، وهذا ليس مفهومًا جيدًا بشكل كافٍ من قبل المستخدمين الذين قاموا بتثبيت --user ).

يبدو أن المشكلة هي أن PATH (للعثور على الأوامر) و sys.path (للعثور على واردات Python) لهما أولويات معاكسة ، لذلك يحاول نص المشغل من تثبيت واحد تحميل الحزمة من آخر. من المفترض أنها ليست خاصة بالنقطة - فقد تؤثر على أي حزمة تقوم بتثبيت برنامج نصي.

لست متأكدًا مما يمكننا فعله حيال ذلك ، إذا كان هناك أي شيء ، لكنني أوافق على أن الأمر يستحق التفكير فيه.

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

هل تقصد إهمال البرنامج النصي للغلاف pip ، أو إهمال البرامج النصية المجمعة باعتبارها شيء يمكن للنقطة تثبيته؟

أنا بالتأكيد -1 في الأخير - القدرة على تثبيت الأوامر مفيدة للغاية ، حتى لو تسبب في مشاكل.

قد يكون تجاهل pip لصالح python -m pip أكثر منطقية. عندما يتم تثبيت النقطة في بيئة Python التي تعمل بها ، فمن المنطقي أن تكون واضحًا أيهما هو. لكنه سيظل يمثل خسارة في الراحة ، واستراحة كبيرة فيما اعتاد الناس عليه.

لقد قصدت بالتحديد البرامج النصية المجمعة لـ pip نفسها. موافق على أنها خسارة في الملاءمة ، ولن أعارض الاحتفاظ بها بشكل ما (يقترح # 3164 وجود مشروع جديد pip-cli يوفر الأغلفة فقط) ولكن النقطة الأساسية ستكون python -m pip ليكون الوسيلة المدعومة لتشغيل النقطة.

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

وبالمثل ، يحذر pipenv مما إذا كان المستخدم موجودًا بالفعل في Virtualenv ، وإذا كان الأمر كذلك يستخدم Virtualenv بدلاً من إدارته ، بعد إرسال تحذير.

حسنًا ، نشير هنا إلى أنه تمت الموافقة على # 7002 بواسطة 3 من أصل 6 مشرفين على صيانة النقاط في هذه المرحلة.

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

• هل نريد آلية لإلغاء الاشتراك صراحة في عمليات تثبيت المستخدم بمجرد التبديل إليها افتراضيًا؟ إذا كان الأمر كذلك ، كيف سيكون مختلفًا عن --no-user ؟ (أنا مشترك لإعادة تسمية --no-user إلى --global على أنه إلغاء الاشتراك الصريح).
• ما هي استراتيجيتنا "الانتقالية"؟
  
  
  
  • كيف نريد توصيل هذا التغيير؟
  
  
  • اطلب من المستخدمين توخي الحذر عند إجراء هذه الترقية؟
  
  
  • ما أنواع المشكلات التي نتوقع أن يثيرها المستخدمون ، عند تنفيذ هذا التغيير + إصداره؟
  
  

أود أن أقول إن اسم --global خاطئ إذا كنت داخل بيئة. بالنسبة إلى flit install ، فإن عكس --user هو --env ، والذي قصدته بشكل فضفاض أن يتضمن "بيئة Python للنظام" ، لكنني لا أعتقد أن هذا واضح تمامًا أيضًا. ربما لا يزال --no-user هو الخيار الأفضل - من الواضح أنه عكس --user .

أعتقد أن --no-user (أو متغير البيئة المكافئ أو إدخال التكوين) يجب أن يعيدك إلى السلوك الحالي ، نظرًا لأن القيمة الافتراضية حاليًا هي user = False .

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

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

إنه يقوم بالتبديل من تثبيتات غير المستخدم إلى عمليات التثبيت التي يقوم بها المستخدم بشكل افتراضي.

ليس (على سبيل المثال) على Windows ، حيث (افتراضيًا) يكون تثبيت Python عبارة عن تثبيت لكل مستخدم وتكون حزم الموقع قابلة للكتابة افتراضيًا. هذا شيء أفضله بشكل عام حول # 7002 ، لأن تجربتي منذ فتح هذه المشكلة (# 1668) هي أنه من السهل جدًا الدخول في فوضى مع البيئات "المختلطة" حيث يكون لديك حزم مثل Pip مثبتة في حزم الموقع وموقع المستخدم. لذلك أنا الآن أؤيد إجراء عمليات تثبيت النظام إذا كان ذلك ممكنًا ، ولا أقوم بتثبيتات المستخدم إلا في حالات مثل Pythons التي يديرها نظام Linux ، حيث لا يمكن الكتابة إلى حزم المواقع.

وقد قلت ذلك:

1. يبدو أنه لا جدوى من الخيار --no-user ، لأن # 7002 يعني أنك تحصل على تثبيت مستخدم فقط في حالة فشل تثبيت النظام على أي حال.
2. أكبر شيء أعتقد أننا بحاجة إلى التواصل معه فيما يتعلق بالانتقال هو أن الناس بحاجة إلى توخي الحذر الشديد بشأن عمليات التثبيت المتعددة ، وهذا شيء لا يمكن التعامل معه إلا من خلال فهم المستخدم وتعليمه ، وليس من خلال أي حل مؤقت. إنها في الأساس مشكلة أساسية في بايثون. يمكننا تمديد pip check للإبلاغ عندما يكون هناك موقع ويقوم المستخدم بتثبيت حزمة ويكون المستخدم يقوم بتظليل الموقع ، على ما أعتقد ...

يبدو أنه لا فائدة من خيار - لا مستخدم

لكي نكون واضحين ، هذا موجود بالفعل ، على الرغم من أنه ربما لا يكون مفيدًا في كثير من الأحيان. إذا كان لديك user=true في ملف التكوين ، فيجب أن يتجاوز --no-user ذلك.

لكي نكون واضحين ، هذا موجود بالفعل

آسف ، كان يجب أن أكون أكثر وضوحًا. لا أرى أي فائدة من وجود "آلية لإلغاء الاشتراك بشكل صريح في عمليات تثبيت المستخدم بمجرد التبديل إليها افتراضيًا" ، على الأقل بمعنى أنني أفترض أن pradyunsg يعني ، وهو يتعلق بإلغاء الاشتراك في السلوك # 7002 ، والذي ليس هو نفسه "التبديل إلى تثبيت المستخدم افتراضيًا" ، كما قلت.

في الواقع ، لست متأكدًا من أن هذا أوضح ؛-) ربما كل ما أريد قوله هو "لسنا بحاجة إلى أي خيارات أكثر من تلك التي لدينا حاليًا" ...

حسنًا ... pfmoore بعد # 7002 ، ما المطلوب لاستدعاء حل هذه المشكلة؟

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

pradyunsg نظرًا لأنني الآن أقل ميلًا للشعور بأن --user كافتراضي هو فكرة جيدة ما لم تكن ضرورية للغاية (الحالات # 7002 تعالج) أفضل القول أنه يمكننا التخلي عن هذه المشكلة كما لم تعد فكرة جيدة الآن بعد أن تم الانتهاء من # 7002.

بأخذ نقطتي النقطتين كأشياء قد نحتاج إلى احتساب # 7002 كاملاً ، فإن تعليقاتي أعلاه تغطي ذلك.

لقد اتبعت ملاحظات الإصدار هنا.
https://pip.pypa.io/en/stable/news/#id3
"الإعداد الافتراضي هو تثبيت المستخدم (كما لو تم تمرير --user) عندما يكون دليل حزم الموقع الرئيسي غير قابل للكتابة ويتم تمكين حزم موقع المستخدم. (# 1668)"

بنياتي الآن تفشل مع

ERROR: Can not perform a '--user' install. User site-packages are not visible in this virtualenv.

يبدو أن هذا قد تم إصلاحه عن طريق إزالة - المستخدم من أوامر النقطة الخاصة بي.

هل كان هذا السلوك متوقعًا؟ ملاحظات الإصدار لا يبدو أنها تعكس هذا.

الارتباط بالبرنامج النصي الذي فشل الآن في النقطة 20.0.1 (إزالة --user يصلح الفشل الصعب)
https://github.com/lfit/releng-global-jjb/blob/master/shell/python-tools-install.sh

إذا كان صحيحًا أن حزم موقع المستخدم غير قابلة للاستيراد من تلك البيئة ، فهذا هو السلوك المتوقع ، ولكنه متعامد مع هذا PR. تم تقديم هذا الشيك منذ سنوات (# 567) ، لكن يبدو أنه تم كسره مع venv حتى وقت قريب (# 7155). هناك ملاحظة إصدار لذلك:

تعامل بشكل صحيح مع حزم موقع النظام ، في البيئات الافتراضية التي تم إنشاؤها باستخدام venv (PEP 405).

آه نعم ، شكرا لك على تعليقاتك. لقد اكتشفت ذلك ...
كان البرنامج النصي الخاص بي يملأ .local / bin /
عندما جريت

python3 -m venv ~/.local

ثم في غلاف تسجيل الدخول إلى ubuntu (#! / bin / bash -l). تتم إضافة local / bin إلى المسار (لذا فإن استدعاء python3 يستدعي الآن ملف .local / bin / python3 القابل للتنفيذ) وهو ما لا نريده.
لم أحتاج مطلقًا إلى تشغيل python3 -m venv ~ / .local
أو استدعاء البرامج النصية الخاصة بي من غلاف تسجيل الدخول ، وتؤدي إزالة كلتا المشكلتين أو أي منهما إلى إصلاحها.

#fresh ubuntu docker
root<strong i="13">@7d8107816f64</strong>:/# python3 -m pip install  --user --upgrade pip
Successfully installed pip-20.0.1
root<strong i="14">@7d8107816f64</strong>:/# python3 -m pip --version
pip 20.0.1 from /root/.local/lib/python3.6/site-packages/pip (python 3.6)
root<strong i="15">@7d8107816f64</strong>:/# ls root/.local/bin/pip
pip     pip3    pip3.6
#Now we populate ~/.local/bin/
root<strong i="16">@7d8107816f64</strong>:/# python3 -m venv ~/.local
root<strong i="17">@7d8107816f64</strong>:/# ls root/.local/bin/
activate          activate.fish     easy_install-3.6  pip3              python
activate.csh      easy_install      pip               pip3.6            python3
root<strong i="18">@7d8107816f64</strong>:/# ./root/.local/bin/python --version
Python 3.6.9
root<strong i="19">@7d8107816f64</strong>:/# ./root/.local/bin/python -m pip install  --user --upgrade pip
ERROR: Can not perform a '--user' install. User site-packages are not visible in this virtualenv.

لذلك إذا قمنا بتشغيل الملف القابل للتنفيذ .local / bin / python ، فلن نتمكن من تثبيت التثبيت مع --user

أوه ، لقد فاتني أنك كنت تفعل python3 -m venv ~/.local . من المحتمل أن يؤدي هذا إلى إرباك أدوات مثل النقطة ، لأن ~/.local هو البادئة لعمليات التثبيت --user (على Linux). venvs و --user طريقتان _ مختلفتان _ يمكنك من خلالهما تثبيت الحزم دون إجراء تغييرات على مستوى النظام: يجب استخدام أحدهما أو الآخر. إنشاء venv في ~/.local يجعل بعض الهجين غريبًا من الاثنين.

يُفترض أن السلوك الجديد مناسب للكثيرين ، لكن تثبيتات "المستخدم" سببت لي بعض الحزن كمطور ويب - غالبًا ما أحتاج إلى إعداد Virtualenvs التي سيتم نشرها على أجهزة الإنتاج الخاصة بنا ، وإذا تم تثبيت أي حزمة في مكتبة المستخدم الخاصة بي ، ثم افتراضيًا ، سيرفض pip تثبيته على Virtualenv الذي أقوم بتحضيره ، وسيستمر الخروج بنجاح . يتم دفن الإخطار الذي يفيد بأنه قرر عدم تثبيت الحزمة داخل 30 أو 40 صفحة من الإخراج من البرنامج النصي الذي أستخدمه لإعداد Virtualenv. التأثير النهائي هو أنه بمجرد نشر Virtualenv ، لم تعد الحزم من dir home الخاص بي متوفرة ، لذلك بعض الحزم العشوائية مفقودة من تطبيق الويب الخاص بالإنتاج ، وقد انتهى الأمر.

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

بالنسبة للآخرين الذين عانوا من مشكلات مماثلة ، هناك عدة طرق للتغلب على هذه المشكلة:

• أضف --force-reinstall إلى كل أسطر الأوامر pip install في البرامج النصية وما إلى ذلك
• احذف ~/.local/lib/python* وعدّل ~/.pip/pip.conf لإضافة user = no في قسم global :

[global]
user = no

• افعل شيئًا أكثر تشددًا ، مثل تغيير ~/.local/lib إلى ملف بدلاً من دليل: smirk:

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

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

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

إذا قمت بإنشاء Virtualenvs باستخدام الخيار --system-site-packages (أو الإصدارات القديمة جدًا من virtualenv حيث كان ذلك هو الخيار الافتراضي) ، فإنها تعمل بمثابة تراكب على الحزم التي قمت بتثبيتها بطريقة أخرى ، سواء على مستوى النظام أو في منزلك الدليل. إذا كنت تريد أن تكون حزم النظام مرئية ولكن ليس حزم المستخدم ، فيمكنك تشغيل Python باستخدام الخيار -s أو متغير البيئة PYTHONNOUSERSITE .

أوه! أنا آسف جدا ، أنت على حق تماما. تنبيهات سياسة حزم مواقع النظام الغريبة لمنظمتي مرة أخرى. شكرا لتوضيح بعض الحلول.

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

يتم الإغلاق تماشياً مع https://github.com/pypa/pip/issues/1668#issuecomment -544569965.

شكرا جزيلا @ takluyver! ^> ^

takluyver شكرًا لك على حل المشكلة التي أزعجتني لفترة طويلة
لكنني لاحظت أنه عند تثبيت الحزم مع مستخدمين لا يتمتعون بامتيازات ، فإن Windows 10 python 3.8.2 مع pip 20.0.2 لا يزال يفشل بشدة.

ERROR: Exception:
Traceback (most recent call last):
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\cli\base_command.py", line 186, in _main
    status = self.run(options, args)
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\commands\install.py", line 253, in run
    options.use_user_site = decide_user_install(
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\commands\install.py", line 604, in decide_user_install
    if site_packages_writable(root=root_path, isolated=isolated_mode):
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\commands\install.py", line 548, in site_packages_writable
    return all(
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\commands\install.py", line 549, in <genexpr>
    test_writable_dir(d) for d in set(get_lib_location_guesses(**kwargs))
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\utils\filesystem.py", line 140, in test_writable_dir
    return _test_writable_dir_win(path)
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\utils\filesystem.py", line 153, in _test_writable_dir_win
    fd = os.open(file, os.O_RDWR | os.O_CREAT | os.O_EXCL)
PermissionError: [Errno 13] Permission denied: 'c:\\program files (x86)\\python38-32\\Lib\\site-packages\\accesstest_deleteme_fishfingers_custard_m59lch'

اعتقدت أن هذا قد يتسبب في أن يكون OSError errno errno.EACCES لكن errno.EPERM .

catPill يرجى فتح إصدار جديد حتى يمكن تتبعه بشكل صحيح. من المعقول تمامًا أن أفتقد شيئًا ما على Windows.