جدول المحتويات
- لماذا الحاجة إلى البيئات الافتراضية؟
- ما هي البيئة الافتراضية؟
- استخدام البيئات الافتراضية
- كيف تعمل البيئة الافتراضية؟
- إدارة البيئات الافتراضية باستخدام virtualenvwrapper
- استخدام إصدارات مختلفة من بايثون
- خاتمة
في هذه المقالة ، سنوضح لك كيفية استخدام البيئات الافتراضية لإنشاء وإدارة بيئات منفصلة لمشاريع Python الخاصة بك ، كل منها يستخدم إصدارات مختلفة من Python للتنفيذ. سنلقي نظرة أيضًا على كيفية تخزين تبعيات Python وحلها.
- تحديث 2018-01-12: توضيح استخدام pyenv مقابل venv في Python 3.6+
- تم التحديث في 2016-06-11: تمت إضافة قسم حول تغيير إصدارات Python باستخدام virtualenv
لماذا الحاجة إلى البيئات الافتراضية؟
تمتلك Python ، مثل معظم لغات البرمجة الحديثة الأخرى ، طريقتها الفريدة في تنزيل الحزم (أو الوحدات) وتخزينها وحلها. في حين أن هذا له مزاياه ، كانت هناك بعض القرارات المثيرة للاهتمام التي تم اتخاذها بشأن تخزين الحزمة ودقتها ، مما أدى إلى بعض المشكلات – خاصةً فيما يتعلق بكيفية ومكان تخزين الحزم.
هناك عدد قليل من المواقع المختلفة حيث يمكن تثبيت هذه الحزم على نظامك. على سبيل المثال ، يتم تخزين معظم حزم النظام في دليل تابع للمسار المخزن في sys.prefix.
في نظام التشغيل Mac OS X ، يمكنك بسهولة العثور على المكان الذي يشير إليه sys.prefix لاستخدام صدفة Python:
>>> import sys
>>> sys.prefix
'/System/Library/Frameworks/Python.framework/Versions/3.5'
أكثر صلة بموضوع هذه المقالة ، يتم عادةً وضع حزم الجهات الخارجية المثبتة باستخدام easy_install أو pip في أحد الأدلة التي يشير إليها site.getsitepackages:
>>> import site
>>> site.getsitepackages()
[
'/System/Library/Frameworks/Python.framework/Versions/3.5/Extras/lib/python',
'/Library/Python/3.5/site-packages'
]
إذن ، لماذا كل هذه التفاصيل الصغيرة مهمة؟
من المهم معرفة ذلك لأنه ، بشكل افتراضي ، سيستخدم كل مشروع على نظامك هذه الأدلة نفسها لتخزين واسترداد حزم الموقع (مكتبات الطرف الثالث). للوهلة الأولى ، قد لا تبدو هذه مشكلة كبيرة ، وهي ليست كذلك بالفعل لحزم النظام (الحزم التي تعد جزءًا من مكتبة Python القياسية) ، ولكنها مهمة لحزم الموقع.
ضع في اعتبارك السيناريو التالي حيث لديك مشروعان: ProjectA و ProjectB ، وكلاهما يعتمد على نفس المكتبة ، ProjectC. تصبح المشكلة واضحة عندما نبدأ في طلب إصدارات مختلفة من ProjectC. ربما يحتاج ProjectA إلى الإصدار 1.0.0 ، بينما يتطلب ProjectB الإصدار 2.0.0 الأحدث ، على سبيل المثال.
هذه مشكلة حقيقية لبايثون لأنها لا تستطيع التمييز بين الإصدارات في دليل حزم الموقع. لذلك سيكون كلا الإصدارين 1.0.0 و v2.0.0 موجودين في نفس الدليل بنفس الاسم:
/System/Library/Frameworks/Python.framework/Versions/3.5/Extras/lib/python/ProjectCنظرًا لأنه يتم تخزين المشاريع وفقًا لاسمها فقط ، فلا يوجد تمييز بين الإصدارات. وبالتالي ، سيُطلب من كلا المشروعين ، ProjectA و ProjectB ، استخدام نفس الإصدار ، وهو أمر غير مقبول في كثير من الحالات.
هذا هو المكان الذي تلعب فيه البيئات الافتراضية وأدوات virtualenv / venv …
ما هي البيئة الافتراضية؟
الغرض الأساسي من بيئات Python الافتراضية هو إنشاء بيئة معزولة لمشاريع Python. هذا يعني أن كل مشروع يمكن أن يكون له تبعياته الخاصة ، بغض النظر عن التبعيات التي يمتلكها كل مشروع آخر.
في مثالنا الصغير أعلاه ، نحتاج فقط إلى إنشاء بيئة افتراضية منفصلة لكل من ProjectA و ProjectB ، وسنكون على ما يرام. وستكون كل بيئة بدورها قادرة على الاعتماد على أي إصدار من ProjectC تختاره ، بغض النظر عن الأخرى.
إن الشيء العظيم في هذا هو أنه لا توجد حدود لعدد البيئات التي يمكنك امتلاكها لأنها مجرد أدلة تحتوي على بعض البرامج النصية. بالإضافة إلى ذلك ، يتم إنشاؤها بسهولة باستخدام أدوات سطر الأوامر virtualenv أو pyenv.
استخدام البيئات الافتراضية
للبدء ، إذا كنت لا تستخدم Python 3 ، فستحتاج إلى تثبيت أداة virtualenv مع النقطة:
$ pip install virtualenv
إذا كنت تستخدم Python 3 ، فيجب أن يكون لديك بالفعل وحدة venv من المكتبة القياسية مثبتة.
ملاحظة: من الآن فصاعدًا ، سنفترض أنك تستخدم أداة venv الأحدث ، نظرًا لوجود بعض الاختلافات بينها وبين virtualenv فيما يتعلق بالأوامر الفعلية. في الواقع ، على الرغم من أنها أدوات مختلفة تمامًا.
ابدأ بإنشاء دليل جديد للعمل معه:
$ mkdir python-virtual-environments && cd python-virtual-environmentsأنشئ بيئة افتراضية جديدة داخل الدليل:
# Python 2:
$ virtualenv env
# Python 3
$ python3 -m venv envملاحظة: بشكل افتراضي ، لن يتضمن هذا أيًا من حزم موقعك الحالية.
يتميز نهج Python 3 venv بأنه يجبرك على اختيار إصدار معين من مترجم Python 3 الذي يجب استخدامه لإنشاء البيئة الافتراضية. هذا يتجنب أي التباس حول تثبيت Python الذي تستند إليه البيئة الجديدة.
من Python 3.3 إلى 3.4 ، كانت الطريقة الموصى بها لإنشاء بيئة افتراضية هي استخدام أداة سطر أوامر pyvenv التي تأتي أيضًا مع تثبيت Python 3 بشكل افتراضي. ولكن في حالة الإصدار 3.6 وما فوق ، فإن python3 -m venv هو السبيل للذهاب.
في المثال أعلاه ، يُنشئ هذا الأمر دليلًا يسمى env ، والذي يحتوي على بنية دليل مشابه لذلك:
├── bin
│ ├── activate
│ ├── activate.csh
│ ├── activate.fish
│ ├── easy_install
│ ├── easy_install-3.5
│ ├── pip
│ ├── pip3
│ ├── pip3.5
│ ├── python -> python3.5
│ ├── python3 -> python3.5
│ └── python3.5 -> /Library/Frameworks/Python.framework/Versions/3.5/bin/python3.5
├── include
├── lib
│ └── python3.5
│ └── site-packages
└── pyvenv.cfg
إليك ما يحتويه كل مجلد:
- bin: الملفات التي تتفاعل مع البيئة الافتراضية
- تشمل: رؤوس C التي تجمع حزم Python
- lib: نسخة من إصدار Python مع مجلد حزم الموقع حيث يتم تثبيت كل تبعية
علاوة على ذلك ، هناك نسخ من بعض أدوات Python المختلفة أو روابط رمزية لها بالإضافة إلى ملفات Python التنفيذية نفسها. تُستخدم هذه الملفات لضمان تنفيذ جميع تعليمات وأوامر Python في سياق البيئة الحالية ، وهي الطريقة التي يتم بها تحقيق العزلة عن البيئة العالمية. سنشرح ذلك بمزيد من التفصيل في القسم التالي.
الأكثر إثارة للاهتمام هي نصوص التنشيط في دليل bin. تُستخدم هذه البرامج النصية لإعداد shell الخاص بك لاستخدام لغة Python القابلة للتنفيذ الخاصة بالبيئة وحزم الموقع الخاصة بها افتراضيًا.
من أجل استخدام حزم / موارد هذه البيئة بشكل منفصل ، تحتاج إلى “تنشيطها”. للقيام بذلك ، ما عليك سوى تشغيل ما يلي:
$ source env/bin/activate
(env) $
لاحظ كيف أصبح موجهك الآن مسبوقًا باسم بيئتك (env ، في حالتنا). هذا هو المؤشر على أن env نشط حاليًا ، مما يعني أن ملف Python القابل للتنفيذ لن يستخدم سوى حزم وإعدادات هذه البيئة.
لإظهار عزل الحزمة أثناء العمل ، يمكننا استخدام وحدة bcrypt كمثال. لنفترض أن لدينا bcrypt مثبتًا على مستوى النظام ولكن ليس في بيئتنا الافتراضية.
قبل أن نختبر هذا ، نحتاج إلى العودة إلى سياق “النظام” بتنفيذ إلغاء التنشيط:
(env) $ deactivate
$
الآن عادت جلسة shell إلى وضعها الطبيعي ، ويشير أمر python إلى تثبيت Python العام. تذكر أن تفعل ذلك كلما انتهيت من استخدام بيئة افتراضية محددة.
الآن ، قم بتثبيت bcrypt واستخدمه لتجزئة كلمة المرور:
$ pip -q install bcrypt
$ python -c "import bcrypt; print(bcrypt.hashpw('password'.encode('utf-8'), bcrypt.gensalt()))"
$2b$12$vWa/VSvxxyQ9d.WGgVTdrell515Ctux36LCga8nM5QTW0.4w8TXXiإليك ما يحدث إذا حاولنا نفس الأمر عند تنشيط البيئة الافتراضية:
$ source env/bin/activate
(env) $ python -c "import bcrypt; print(bcrypt.hashpw('password'.encode('utf-8'), bcrypt.gensalt()))"
Traceback (most recent call last):
File "<string>", line 1, in <module>
ImportError: No module named 'bcrypt'
كما ترى ، يتغير سلوك الأمر python -c “import bcrypt …” بعد المصدر env / bin / activation call.
في إحدى الحالات ، لدينا bcrypt متاح لنا ، وفي المرة التالية ليس لدينا. هذا هو نوع الفصل الذي نتطلع إلى تحقيقه باستخدام البيئات الافتراضية ، والذي يمكن تحقيقه الآن بسهولة.
كيف تعمل البيئة الافتراضية؟
ماذا يعني بالضبط “تنشيط” البيئة؟ يمكن أن تكون معرفة ما يجري تحت الغطاء أمرًا مهمًا جدًا للمطور ، خاصة عندما تحتاج إلى فهم بيئات التنفيذ ، ودقة التبعية ، وما إلى ذلك.
لشرح كيفية عمل ذلك ، دعنا أولاً نتحقق من مواقع ملفات بيثون التنفيذية المختلفة. مع البيئة “غير نشطة” ، قم بتشغيل ما يلي:
$ which python
/usr/bin/python
الآن ، قم بتنشيطه وتشغيل الأمر مرة أخرى:
$ source env/bin/activate
(env) $ which python
/Users/michaelherman/python-virtual-environments/env/bin/python
بعد تنشيط البيئة ، نحصل الآن على مسار مختلف لملف Python القابل للتنفيذ لأنه ، في بيئة نشطة ، يتم تعديل متغير البيئة $ PATH بشكل طفيف.
لاحظ الفرق بين المسار الأول في $ PATH قبل التنشيط وبعده:
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:
$ source env/bin/activate
(env) $ echo $PATH
/Users/michaelherman/python-virtual-environments/env/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:
في المثال الأخير، أصبح دليل bin لبيئتنا الافتراضية الآن في بداية المسار. هذا يعني أنه أول دليل يتم البحث عنه عند تشغيل ملف تنفيذي في سطر الأوامر. وبالتالي ، تستخدم القشرة مثيل بيئتنا الافتراضية من Python بدلاً من الإصدار على مستوى النظام.
ملاحظة: تميل الحزم الأخرى التي تجمع Python ، مثل Anaconda ، أيضًا إلى معالجة مسارك عند تنشيطها. فقط كن على علم بهذا في حالة مواجهة مشاكل مع بيئاتك الأخرى. يمكن أن يصبح هذا مشكلة إذا بدأت في تنشيط بيئات متعددة في وقت واحد.
وهذا يثير الأسئلة التالية:
- ما هو الفرق بين هذين الملفين التنفيذيين على أي حال؟
- كيف يمكن لبيثون القابل للتنفيذ في البيئة الافتراضية استخدام شيء آخر غير حزم مواقع النظام؟
يمكن تفسير ذلك من خلال كيفية بدء تشغيل Python ومكان وجودها على النظام. في الواقع ، لا يوجد أي فرق بين هذين الملفين التنفيذيين في بايثون. إن ما يهم هو مواقع دليلهم.
عندما يبدأ Python ، فإنه ينظر إلى مسار ثنائي الخاص به. في بيئة افتراضية ، يكون الأمر في الواقع مجرد نسخة أو رابط رمزي من نظام Python الثنائي. ثم يقوم بتعيين موقع sys.prefix و sys.exec_prefix بناءً على هذا الموقع ، مع حذف جزء الحاوية من المسار.
ثم يتم استخدام المسار الموجود في sys.prefix لتحديد موقع دليل حزم الموقع من خلال البحث في المسار النسبي lib / pythonX.X / site -pack / ، حيث X.X هو إصدار Python الذي تستخدمه.
في مثالنا ، يوجد الملف الثنائي في / Users / michaelherman / python-virtual-environment / env / bin ، مما يعني أن sys.prefix سيكون / Users / michaelherman / python-virtual-environment / env ، وبالتالي حزم الموقع الدليل المستخدم سيكون /Users/michaelherman/python-virtual-environment/env/lib/pythonX.X/site-packages. أخيرًا ، يتم تخزين هذا المسار في مصفوفة sys.path ، والتي تحتوي على جميع المواقع التي يمكن أن تتواجد فيها الحزمة.
إدارة البيئات الافتراضية باستخدام virtualenvwrapper
بينما تحل البيئات الافتراضية بالتأكيد بعض المشكلات الكبيرة في إدارة الحزم ، إلا أنها ليست مثالية. بعد إنشاء بعض البيئات ، ستبدأ في ملاحظة أنها تخلق بعض المشكلات الخاصة بها ، والتي يدور معظمها حول إدارة البيئات نفسها. للمساعدة في ذلك ، تم إنشاء أداة virtualenvwrapper. إنها مجرد بعض البرامج النصية المجمعة حول أداة virtualenv الرئيسية.
فيما يلي بعض الميزات الأكثر فائدة لبرنامج virtualenvwrapper:
- ينظم جميع بيئاتك الافتراضية في مكان واحد
- يوفر طرقًا لمساعدتك في إنشاء البيئات وحذفها ونسخها بسهولة
- يوفر أمرًا واحدًا للتبديل بين البيئات
بينما قد تبدو بعض هذه الميزات صغيرة أو غير مهمة ، ستعرف قريبًا أنها أدوات مهمة لإضافتها إلى سير عملك.
للبدء ، يمكنك تنزيل الغلاف بنقطة:
$ pip install virtualenvwrapperملاحظة: بالنسبة لنظام التشغيل Windows ، يجب عليك استخدام virtualenvwrapper-win بدلاً من ذلك.
بمجرد تثبيته ، سنحتاج إلى تنشيط وظائف shell الخاصة به. يمكننا القيام بذلك عن طريق تشغيل المصدر على البرنامج النصي Virtualenvwrapper.sh المثبت. عند تثبيته لأول مرة باستخدام نقطة ، سيخبرك ناتج التثبيت بالموقع الدقيق لـ virtualenvwrapper.sh. أو يمكنك ببساطة تشغيل ما يلي:
$ which virtualenvwrapper.sh
/usr/local/bin/virtualenvwrapper.sh
باستخدام هذا المسار ، أضف الأسطر الثلاثة التالية إلى ملف بدء تشغيل shell الخاص بك. إذا كنت تستخدم Bash shell ، يمكنك وضع هذه الأسطر إما في ملف ~ / .bashrc أو في الملف ~ / .profile. بالنسبة للأصداف الأخرى ، مثل zsh أو csh أو fish ، ستحتاج إلى استخدام ملفات بدء التشغيل الخاصة بذلك shell. كل ما يهم هو أن هذه الأوامر يتم تنفيذها عند تسجيل الدخول أو فتح صدفة جديدة:
export WORKON_HOME=$HOME/.virtualenvs # Optional
export PROJECT_HOME=$HOME/projects # Optional
source /usr/local/bin/virtualenvwrapper.shملاحظة: ليس مطلوبًا تحديد متغيرات بيئة WORKON_HOME و PROJECT_HOME. يحتوي virtualenvwrapper على قيم افتراضية لهؤلاء ، ولكن يمكنك تجاوزها عن طريق تحديد القيم.
أخيرًا ، أعد تحميل ملف بدء التشغيل:
$ source ~/.bashrcيجب أن يكون هناك دليل موجود الآن على WORKON_HOME $ يحتوي على جميع بيانات / ملفات virtualenvwrapper:
$ echo $WORKON_HOME
/Users/michaelherman/.virtualenvs
سيكون لديك الآن أيضًا أوامر shell متاحة لك لمساعدتك في إدارة البيئات. فيما يلي عدد قليل من الخيارات المتاحة:
- يعمل على
- تعطيل
- مكفيرتولينف
- cdvirtualenv
- rmvirtualenv
لمزيد من المعلومات حول الأوامر والتثبيت وتكوين Virtualenvwrapper ، تحقق من الوثائق.
الآن ، في أي وقت تريد فيه بدء مشروع جديد ، عليك فقط القيام بذلك:
$ mkvirtualenv my-new-project
(my-new-project) $
سيؤدي هذا إلى إنشاء وتنشيط بيئة جديدة في الدليل الموجود في $ WORKON_HOME ، حيث يتم تخزين جميع بيئات Virtualenvwrapper.
للتوقف عن استخدام هذه البيئة ، ما عليك سوى إلغاء تنشيطها كما كان من قبل:
(my-new-project) $ deactivate
$
إذا كان لديك العديد من البيئات للاختيار من بينها ، فيمكنك سردها جميعًا باستخدام وظيفة workon:
$ workon
my-new-project
my-django-project
web-scraper
أخيرًا ، إليك كيفية التفعيل:
$ workon web-scraper
(web-scraper) $
إذا كنت ترغب في أن تكون قادرًا على استخدام أداة واحدة والتبديل بين إصدارات Python ، فسوف يسمح لك virtualenv بفعل ذلك. يحتوي virtualenv على معلمة -p تتيح لك تحديد إصدار Python الذي تريد استخدامه. قم بدمج ذلك مع أي أمر ، ويمكننا بسهولة تحديد نسختك المفضلة من Python لاستخدامها بطريقة بسيطة. على سبيل المثال ، لنفترض أننا نريد Python 3 كإصدار مفضل لدينا:
$ virtualenv -p $(which python3) blog_virtualenv
سيؤدي ذلك إلى إنشاء بيئة Python 3 جديدة.
كيف يعمل هذا؟ الأمر الذي يتم استخدامه للبحث عن أمر معين في متغير $ PATH وإعادة المسار الكامل إلى هذا الأمر. لذلك ، تم إرجاع المسار الكامل إلى python3 ، إلى المعلمة -p التي تأخذ PYTHON_EXE. يمكن أيضًا استخدام هذا مع python2 أيضًا. فقط استبدل python3 بـ python2 (أو python إذا كان النظام افتراضيًا هو python2).
الآن لست مضطرًا لتذكر مكان تثبيت بيئاتك. يمكنك حذفها أو نسخها بسهولة كما يحلو لك ، ويكون دليل مشروعك أقل تشوشًا!
استخدام إصدارات مختلفة من بايثون
بخلاف أداة virtualenv القديمة ، لا تدعم pyvenv إنشاء بيئات بإصدارات عشوائية من Python ، مما يعني أنك عالق في استخدام تثبيت Python 3 الافتراضي لجميع البيئات التي تنشئها. بينما يمكنك ترقية بيئة إلى أحدث إصدار من نظام Python (عبر خيار –upgrade) ، إذا تغيرت ، فلا يزال يتعذر عليك تحديد إصدار معين.
توجد عدة طرق لتثبيت Python ، لكن القليل منها سهل أو مرن بدرجة كافية لإلغاء تثبيت إصدارات مختلفة من البرنامج الثنائي وإعادة تثبيتها.
هذا هو المكان الذي يأتي فيه pyenv للعب.
على الرغم من التشابه في الأسماء (pyvenv vs pyenv) ، فإن pyenv مختلفة من حيث أن تركيزها ينصب على مساعدتك في التبديل بين إصدارات Python على مستوى النظام وكذلك على مستوى المشروع. في حين أن الغرض من pyvenv هو فصل الوحدات النمطية ، فإن الغرض من pyenv هو فصل إصدارات Python.
يمكنك البدء بتثبيت pyenv إما مع Homebrew (على OS X) أو مشروع pyenv-installer:
البيرة
$ brew install pyenv
المثبت pyenv
$ curl -L https://raw.githubusercontent.com/yyuu/pyenv-installer/master/bin/pyenv-installer | bashملاحظة: للأسف ، لا يدعم pyenv نظام التشغيل Windows. بعض البدائل التي يمكنك تجربتها هي pywin و anyenv.
بمجرد أن يكون لديك pyenv على نظامك ، إليك بعض الأوامر الأساسية التي ربما تكون مهتمًا بها:
$ pyenv install 3.5.0 # Install new version
$ pyenv versions # List installed versions
$ pyenv exec python -V # Execute 'python -V' using pyenv version
في هذه الأسطر القليلة ، نقوم بتثبيت الإصدار 3.5.0 من Python ، ونطلب من pyenv إظهار جميع الإصدارات المتاحة لنا ،
ثم تنفيذ الأمر python -V باستخدام الإصدار المحدد من pyenv. لمنحك المزيد من التحكم ،
يمكنك بعد ذلك استخدام أي من الإصدارات المتاحة للاستخدام "العام" أو الاستخدام "المحلي".
يؤدي استخدام pyenv مع الأمر المحلي إلى تعيين إصدار Python لمشروع أو دليل معين عن طريق تخزين
رقم الإصدار في ملف إصدار .python محلي. يمكننا تعيين الإصدار "المحلي" مثل هذا:
$ pyenv local 2.7.11
يؤدي هذا إلى إنشاء ملف .python-version في دليلنا الحالي ، كما ترى هنا:
$ ls -la
total 16
drwxr-xr-x 4 michaelherman staff 136 Feb 22 10:57 .
drwxr-xr-x 9 michaelherman staff 306 Jan 27 20:55 ..
-rw-r--r-- 1 michaelherman staff 7 Feb 22 10:57 .python-version
-rw-r--r-- 1 michaelherman staff 52 Jan 28 17:20 main.py
يحتوي هذا الملف فقط على محتويات "2.7.11". الآن ، عند تنفيذ نص برمجي باستخدام pyenv ،
فسيتم تحميل هذا الملف واستخدام الإصدار المحدد ، على افتراض أنه صالح وموجود على نظامك. بالانتقال إلى مثالنا ،
لنفترض أن لدينا نصًا برمجيًا بسيطًا يسمى main.py في دليل المشروع يبدو كالتالي:
import sys
print('Using version:', sys.version[:5])
كل ما يفعله هو طباعة رقم إصدار ملف Python القابل للتنفيذ المستخدم. باستخدام pyenv والأمر exec ،
يمكننا تشغيل البرنامج النصي بأي من إصدارات Python المختلفة التي قمنا بتثبيتها.
$ python main.py
Using version: 2.7.5
$ pyenv global 3.5.0
$ pyenv exec python main.py
Using version: 3.5.0
$ pyenv local 2.7.11
$ pyenv exec python main.py
Using version: 2.7.11
لاحظ كيف يستخدم pyenv exec python main.py إصدار Python "العالمي" افتراضيًا ،
ولكنه يستخدم الإصدار "المحلي" بعد تعيينه للدليل الحالي.
يمكن أن يكون هذا قويًا جدًا للمطورين الذين لديهم الكثير من المشاريع بمتطلبات إصدار مختلفة.
لا يمكنك فقط تغيير الإصدار الافتراضي بسهولة لجميع المشاريع (عبر العمومية) ، ولكن يمكنك أيضًا تجاوزه لتحديد الحالات الخاصة.
خاتمة
في هذه المقالة ، تعرفت ليس فقط على كيفية تخزين تبعيات Python وحلها ،
ولكن أيضًا كيف يمكنك استخدام أدوات المجتمع المختلفة للمساعدة في التغلب على مشاكل التعبئة والإصدار المختلفة.
كما ترى ، بفضل مجتمع Python الضخم ، هناك عدد غير قليل من الأدوات المتاحة لك للمساعدة
في حل هذه المشكلات الشائعة. أثناء تقدمك كمطور ، تأكد من قضاء بعض الوقت في تعلم كيفية استخدام هذه الأدوات لصالحك.
قد تجد حتى استخدامات غير مقصودة لهم أو تتعلم تطبيق مفاهيم مماثلة على اللغات الأخرى التي تستخدمها.
