مرحبا مرة اخرى تحسبا لبدء سلسلة جديدة في دورة التعلم الآلي ، نريد مشاركة ترجمة للمقالة ، والتي لها علاقة غير مباشرة إلى حد ما مع ML ، ولكنها ستكون بالتأكيد مفيدة لمشتركي مدونتنا.
سألت مارياتا ، مطورة كندية ، على موقع
python-m pip على Twitter ، طالبةً منها أن تتحدث عن هذا المصطلح وتشرح كيف تعمل.
لقد تعلمت مؤخرًا أنك بحاجة إلى كتابة python -m pip بدلاً من تثبيت pip المعتاد ، لكن الآن لا أستطيع تذكر من سمعت. ربما من brettsky أو zooba . هل لدى أي منكم مدونة منشورة حتى أتمكن من مشاركتها مع القراء؟
- Mariatta ( @mariatta ) 29 أكتوبر 2019 ( https://twitter.com/mariatta/status/1189243515739561985؟ref_src=twsrc٪5Etfw )
لست متأكدًا مما قلته لماريتا حول
python -m pip ، لكن هناك كل فرصة لأنني كنت ، لأنني طلبت أن يتم كتابة هذا الإرشادات لتثبيت الحزم باستخدام
PyPI بهذه الطريقة منذ عام 2016. لذلك ، يجب أن تشرح هذه المقالة ماهية
python -m pip ولماذا يجب عليك استخدامها عند بدء
pip .
ما هو بيثون م؟
بالنسبة للمبتدئين ، ينفذ
python -m pip نقطة باستخدام إصدار Python الذي حددته لبيان python. وبالتالي ،
/usr/bin/python3.7 -m pip أنك تقوم بتشغيل
pip للمترجم الموجود في
/usr/bin/python3.7 . يمكنك قراءة
الوثائق حول العلامة
-m إذا كنت لا تعرف كيف تعمل (بالمناسبة ، إنها مفيدة للغاية).
لماذا استخدام python -m pip بدلاً من pip / pip3؟
يمكنك أن تقول: "حسنًا ، لكن لماذا لا يمكنني فقط استخدام
النقطة عن طريق تشغيل أمر
النقطة ؟" الجواب هو: "نعم ، ولكن سيكون لديك سيطرة أقل عليه". سأشرح ما يعنيه "التحكم الأقل" بمثال.
افترض أن لدي نسختين من Python مثبّتة ، على سبيل المثال Python 3.7 و 3.8 (هذا شائع جدًا بين الأشخاص الذين يعملون على Mac OS أو Linux ، ناهيك عن حقيقة أنك ربما تريد اللعب مع Python 3.8 ، وكان لديك بالفعل بيثون 3.7). لذلك ، إذا قمت بكتابة
نقطة في المحطة ، لأي مترجم بيثون سوف تقوم بتثبيت الحزمة؟
بدون معلومات أكثر تفصيلاً لن تعرف الإجابة. أولاً ، ستحتاج إلى فهم ما يكمن في PATH ، أي
/usr/bin يذهب أولاً أو
/usr/local/bin (وهي أكثر الأماكن شيوعًا لتثبيت Python ، بالمناسبة عادةً
/usr/local/ go أولاً). لذلك ، تتذكر أين قمت بتثبيت Python 3.7 و 3.8 وأنها كانت أدلة مختلفة ، وسوف تعرف ما جاء في PATH أولاً. لنفترض أنك قمت بتثبيتهما يدويًا ، ربما تم تثبيت Python 3.7.3 بالفعل على نظامك ، وأنك قمت بتثبيت Python 3.7.5. في هذه الحالة ، يتم تثبيت كلا الإصدارين من Python في
/usr/local/bin . هل يمكن أن تخبرني الآن ما
هي النقطة المرفقة الآن؟
أنت لا تعرف الجواب. إذا كنت لا تعرف متى تم تثبيت كل إصدار ، وكنت تفهم أن أحدث إصدار من
pip تمت كتابته إلى
/usr/local/bin/pip ، لكنك لا تعرف أي مترجم سيستخدم لأمر
pip . يمكنك الآن أن تقول: "أقوم دائمًا بتثبيت أحدث الإصدارات ، وهذا يعني أنه سيتم تثبيت Python 3.8.0 أخيرًا ، لأنه أحدث من 3.7.5 ، على سبيل المثال." حسنًا ، لكن ماذا يحدث عندما يخرج Python 3.7 .6 - لن يتم استخدام
النقطة الخاصة بك من Python 3.8 ، ولكن من Python 3.7.
عند استخدام
python -m pip مع مترجم python المحدد الذي تحتاجه ، يختفي كل الغموض. إذا قمت بكتابة
python3.8 -m pip ، فأنا أعرف بالضبط أي
نقطة سيتم استخدامها وسيتم تثبيت الحزمة لـ Python 3.8 (نفس الشيء سيحدث إذا أشرت إلى python3.7).
إذا كنت تستخدم نظام التشغيل Windows ، فأنت تمتلك حافزًا إضافيًا لاستخدام
python-m pip ، لأنه يسمح
للنقاط بتحديث نفسها. في الغالب لأن
pip.exe يعتبر قيد التشغيل عند كتابة
pip pip --upgrade pip . في هذه المرحلة ، لن يسمح لك Windows بإعادة تثبيت
pip.exe . ومع ذلك ، إذا قمت
بتثبيت python-m pip --upgrade pip ، فأنت تعمل على حل هذه المشكلة عند بدء
تشغيل python.exe وليس
pip.exe .
وماذا يحدث عندما أكون في بيئة نشطة؟
عادة ، عندما أشرح جوهر هذه المقالة للناس ، هناك دائمًا شخص ما سيقول: "أنا دائمًا أستخدم البيئة الافتراضية ، وهذا لا ينطبق علي". حسنًا ، بالنسبة للمبتدئين ، سيكون من الجيد دائمًا استخدام بيئة افتراضية! (سأشرح لماذا أعتقد ذلك في أحد مقالاتي القادمة!) ولكي أكون صادقًا ، ما زلت أصر على استخدام
python-m pip ، حتى لو كان هذا غير ضروري ، بالمعنى الدقيق للكلمة.
أولاً ، إذا كنت تستخدم Windows ، فأنت لا تزال ترغب في استخدام
python-m pip حتى تتمكن من تحديث
pip في بيئتك.
ثانياً ، حتى لو كنت تستخدم نظام تشغيل مختلفًا ، أود أن أقول أنك لا تزال بحاجة إلى استخدام
python-m pip ، لأنه سيعمل بغض النظر عن الموقف. سوف يحذرك من حدوث خطأ إذا نسيت تنشيط البيئة ، وأي شخص يراقبك سوف يتبنى أفضل الممارسات. وأنا شخصياً ، لا أعتقد أن توفير 10 ضغطات المفاتيح هو ثمن كبير لعدم استخدام الممارسة الجيدة. سيساعدك هذا الأمر أيضًا في منع الأخطاء عند كتابة البرامج النصية للتشغيل الآلي التي ستؤدي عمليات غير صحيحة بوضوح إذا نسيت تنشيط البيئة.
أنا شخصياً ، عندما أستخدم أي أداة يعتمد عملها على أي مترجم يبدأ تشغيله ، أستخدم دائمًا
-m ، بغض النظر عما إذا كانت البيئة الافتراضية قد تم تنشيطها أم لا. من المهم دائمًا بالنسبة لي أن أفهم أي مترجم بيثون أستخدمه.
دائما استخدام البيئة! لا تضع كل شيء على التوالي في المترجم العالمي!
عندما نتحدث عن كيفية تجنب الالتباس عند التثبيت في Python ، أود التأكيد على أنه لا ينبغي لنا تثبيت أي شيء في مترجم Python العالمي عندما نعمل محلياً (الحاويات هي مسألة مختلفة تمامًا)! إذا كان هذا هو Python المثبت مسبقًا على نظامك ، فإذا قمت بتثبيت بعض الإصدارات غير المتوافقة من المكتبة التي يعتمد عليها نظام التشغيل الخاص بك ، فسوف تقوم فعلاً بتكسير النظام.
ولكن حتى لو قمت بتثبيت نسخة من
الثعبان بشكل منفصل لك ، فما زلت أوصي بشدة بعدم تثبيته مباشرة في التنمية المحلية. في النهاية ، ستستخدم حزمًا متعددة في مشاريعك قد تتعارض مع بعضها البعض ، ولن تكون لديك فكرة واضحة عن التبعيات داخل مشاريعك. من الأفضل استخدام البيئات لعزل المشاريع الفردية والأدوات الخاصة بهم عن بعضهم البعض. يستخدم مجتمع Python نوعين من البيئات: البيئات الافتراضية وبيئات conda. حتى أن هناك طريقة خاصة لتثبيت أدوات بايثون بمعزل عن غيرها.
إذا كنت بحاجة إلى تثبيت أداة
للتثبيت
المستقل للأداة ، يمكنني أن أوصي باستخدام
pipx . ستتلقى كل أداة بيئة افتراضية خاصة بها ، حتى لا تتعارض مع الآخرين. وبالتالي ، إذا كنت تريد تثبيت واحد فقط ، على سبيل المثال ،
أسود ، فيمكنك العمل دون كسر تثبيت
mypy الوحيد عن طريق
الخطأ .
إذا كنت بحاجة إلى بيئة مشروع (ولا تستخدم conda)
عندما تحتاج إلى إنشاء بيئة لمشروع ما ، فأنا شخصياً أتحول دائمًا إلى
بيئات venv والظاهرية. يتم تضمينه في
stdlib Python ، لذلك فهو متاح دائمًا باستخدام
python-m venv (ما لم تكن ، بالطبع ، تستخدم Debian أو Ubuntu ، وفي هذه الحالة قد تحتاج إلى تثبيت
حزمة python3-venv apt ). تاريخ قليل: لقد قمت بالفعل بحذف أمر
pyvenv القديم الذي قام بتثبيته Python لإنشاء بيئات افتراضية باستخدام
venv ، لنفس الأسباب التي تحتاج إلى استخدام
python -m pip بدلاً من
pip . أي أنه ليس من الواضح لأي مترجم قمت بإنشائه البيئة الافتراضية باستخدام
أمر pyvenv القديم. وتذكر أنك لا تحتاج إلى تنشيط البيئة لاستخدام المترجم الوارد فيها ، لأن
.venv/bin/python يعمل بالإضافة إلى تنشيط البيئة وإدخال أمر
python .
اليوم ، لا يزال بعض المطورين يفضلون
virtualenv ، لأنه متوفر في Python 2 ولديه بعض الميزات الإضافية. شخصياً ، ليس لدي اهتمام كبير بالميزات الإضافية ،
وامتلاك venv المدمج يعني أنني لست بحاجة إلى استخدام
pipx لتثبيت
virtualenv على كل جهاز. ولكن إذا لم يكن
venv يناسب احتياجاتك وتريد بيئة افتراضية ، فراجع إذا كان
virtualenv يقدم ما تحتاجه.
إذا كنت تستخدم كوندا
إذا كنت تستخدم
conda ، فيمكنك استخدام بيئات
conda للحصول على نفس التأثير الذي يمكن أن توفره البيئات الافتراضية التي توفرها
venv . لن أخوض في ما إذا كنت بحاجة إلى استخدام conda أو venv في موقفك المحدد ، ولكن إذا كنت تستخدم
conda ، فأنت تعلم أنه يمكنك (ويجب) إنشاء بيئات
conda لعملك ، بدلاً من تثبيت كل شيء في مكانك الخاص تركيب النظام. لذلك يمكنك أن تفهم بوضوح ما هي التبعيات التي
يمتلكها مشروعك (وهذا هو سبب وجيه لاستخدام
miniconda بدلاً من
anaconda الكامل ، لأن السابق أقل من عُشر حجم الأخير).
هناك دائما الحاويات
يعد العمل في حاوية وسيلة لعدم التعامل مع البيئة على الإطلاق ، لأن "الجهاز" بأكمله سيصبح بيئة منفصلة. حتى تقوم بتثبيت Python في نظام الحاوية ، يجب أن تكون قادرًا على إجراء تثبيت عمومي بأمان حتى تظل الحاوية بسيطة ومباشرة.
أكرر أنك تفهم حقا جوهر ...
لا تقم بتثبيت أي شيء في مترجم Python العالمي الخاص بك! حاول دائمًا استخدام البيئة للتنمية المحلية!لم يعد بإمكاني تحديد عدد المرات التي اضطررت فيها إلى مساعدة شخص ظن أن النقطة مثبتة في مترجم Python ، ولكن تم تثبيتها بالفعل في أخرى. وينطبق هذا المبلغ الهائل أيضًا على تلك اللحظات التي كسر فيها الأشخاص النظام بالكامل أو تساءلوا عن سبب عدم تمكنهم من تثبيت شيء يتناقض مع شيء آخر وضعوه مسبقًا لمشروع آخر ، إلخ. بسبب حقيقة أنهم لم يكلفوا أنفسهم عناء تكوين البيئة على أجهزتهم المحلية.
لذلك ، حتى نتمكن أنت وأنا من النوم بهدوء ، نستخدم
python-m pip ونحاول دائمًا استخدام البيئة.