بيئات بايثون الموحدة: من venv و Conda إلى uv

الرئيسية » Python » بيئات بايثون الموحدة: من venv و Conda إلى uv

إن العمل باستخدام لغة بايثون في مشاريع العالم الحقيقي يكشف بسرعة عن حقيقة مؤلمة: وهي أن تثبيت بايثون عالمي واحد لا يكفي. بمجرد استخدام أكثر من تطبيق في آنٍ واحد، ستواجه تعارضات في التبعيات، وعدم توافق في الإصدارات، ومشكلة "يعمل على جهازي" المعروفة. يحتاج أحد التطبيقات إلى Django 2.2، بينما يتطلب آخر Django 4.2، وتعتمد إحدى مسارات البيانات على pandas 1.3، في حين أن دفتر الملاحظات يتطلب pandas 2.0 - تثبيت كل شيء على مستوى النظام سيؤدي حتماً إلى مشاكل.

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

لماذا تعتبر بيئات بايثون الموحدة مهمة للغاية

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

تحل البيئات الافتراضية هذه المشكلة عن طريق إنشاء أدلة تثبيت منفصلة، ​​كل منها يحتوي على مترجم بايثون وحزم الموقع الخاصة به. تخيّل كل بيئة كعالم بايثون مصغر مستقل: قد يعمل مشروع ما باستخدام Flask 1.1، وآخر باستخدام Flask 2.0، دون أن يتعارض أي منهما مع الآخر. تحديث مكتبة في بيئة واحدة لا يؤثر على باقي المشاريع.

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

تهدف سير العمل الموحدة إلى جمع كل هذا ضمن سلسلة أدوات واحدة متسقة. بدلاً من الخلط اليدوي بين pip و venv و virtualenv و pyenv و Conda و requirements.txt ونصوص shell العشوائية، تحاول الأدوات الحديثة مثل uv تقديم واجهة متماسكة واحدة لإنشاء البيئات وحل التبعيات وقفل الإصدارات وتشغيل الأوامر وحتى بناء ونشر الحزم.

بيئات بايثون الافتراضية الكلاسيكية: venv و virtualenv

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

لإنشاء بيئة افتراضية أساسية، عادةً ما تقوم بتشغيل أمر مثل: python -m venv .venv من داخل مجلد مشروعك. هذا يُنشئ .venv/ دليل يحتوي على كل ما يلزم لتشغيل تطبيقك بشكل مستقل. باستخدام الاسم .venv يُبقيها مخفية في العديد من مستكشفات الملفات والمحطات الطرفية، ويتجنب التعارض مع .env الملفات المستخدمة لمتغيرات البيئة.

بمجرد إنشائها، تقوم بتفعيل البيئة بحيث يستخدم برنامج التشغيل الخاص بك لغة بايثون هذه بدلاً من لغة بايثون الخاصة بالنظام. في نظام ويندوز، يمكنك تشغيل شيء مثل .venv\Scripts\activateفي أنظمة Unix أو macOS، عادةً ما تستخدم source .venv/bin/activateأما بالنسبة للأصداف الأخرى مثل مستشفى الدعم القتالي or سمك، ونصوص التفعيل البديلة مثل activate.csh و activate.fish تم تقديمة.

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

قبل venv كانت هذه الأدوات موجودة، وقد استخدمها المطورون على نطاق واسع. virtualenvولا يزال يحظى بشعبية كبيرة. virtualenv يعمل على إصدارات بايثون القديمة (بما في ذلك بايثون 2) ويوفر خيارات إضافية، مثل اختيار مترجم محدد مع --python=/path/to/python، إنشاء بيئات أسرع من خلال التحسينات، أو التحكم فيما إذا كانت حزم الموقع العالمية مرئية.

منظور مفاهيمي: البيئات بمثابة مطابخ معزولة لبرنامجك

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

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

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

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

إنشاء وإدارة البيئات الافتراضية خطوة بخطوة

إن دورة الحياة الأساسية للبيئة الافتراضية هي نفسها دائمًا: الإنشاء، والتفعيل، وتثبيت الحزم، واستخدامها، ثم إلغاء التفعيل عند الانتهاء. سواء كنت تستخدم venv, virtualenv أو في Conda، لا يتغير النمط حقًا - فقط الأوامر هي التي تتغير.

مع virtualenv، تبدو آلية العمل الأساسية كالتالي: قم بتثبيته أولاً باستخدام pip install virtualenvثم تحقق من ذلك باستخدام virtualenv --versionلإنشاء بيئة، استخدم virtualenv my-env أو تشمل --python=/usr/bin/python3.12 لاستهداف مترجم محدد. ينتج عن ذلك my-env/ مجلد يحتوي على ملفات بايثون الثنائية ومجلدات المكتبات الخاصة بك.

بعد الإنشاء، تقوم بتفعيل البيئة لبدء استخدامها. في الأنظمة الشبيهة بنظام يونكس، source my-env/bin/activate يؤدي الغرض؛ في نظام ويندوز، يمكنك استخدام البرامج النصية الموجودة تحت my-env\Scripts\سيُظهر موجه الأوامر اسم البيئة حتى تتمكن من معرفة أيها نشط حاليًا، وجميعها pip ستقتصر عمليات التثبيت على هذه البيئة فقط.

يصبح تثبيت التبعيات أمرًا بسيطًا بمجرد تفعيل البيئة. يمكنك الجري pip install some-package أو نقطة pip في requirements.txt ملف مع pip install -r requirements.txtإذا كنت ترغب في الحصول على مجموعة الحزم المثبتة حاليًا، فقم بتشغيل pip freeze > requirements.txt حتى يتمكن الآخرون من إعادة إنتاج نفس الإعداد.

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

استخدام pip بفعالية داخل البيئات الافتراضية

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

تتضمن الأوامر الفرعية الشائعة ما يلي: install, uninstall, show, list و freeze. تثبيت أحدث إصدار من حزمة برمجية أمر بسيط للغاية pip install package-nameإذا كنت بحاجة إلى نسخة محددة، يمكنك استخدام == عامل التشغيل، على سبيل المثال pip install requests==2.31.0سيؤدي تشغيل التثبيت مرة أخرى إلى اكتشاف أن الإصدار موجود بالفعل، وسيتخطى إعادة التثبيت ما لم تقم بتغيير الإصدار أو إضافة --upgrade.

للاطلاع على ما هو مثبت حاليًا، pip list يقدم لك نظرة عامة، و pip show package-name يطبع تفاصيل حول حزمة معينة. عندما تحتاج إلى لقطة قابلة للقراءة آلياً للنشر، pip freeze يُخرج جميع الحزم والإصدارات الدقيقة، والتي تكتبها عادةً إلى requirements.txtويمكن بعد ذلك وضع هذا الملف في نظام التحكم في الإصدارات بجانب التعليمات البرمجية الخاصة بك.

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

بينما pip إنها مرنة بشكل لا يصدق، وهي مصممة عمداً لتكون منخفضة المستوى، ولهذا السبب ظهرت أدوات ذات مستوى أعلى فوقها. أدوات مثل pip-tools, Poetry, Pipenv و uv يعتمد على فكرة تثبيت التبعيات، ولكنه يقوم بأتمتة حل المشكلات، والتأمين، وإدارة البيئة، والمزيد.

بيئات كوندا لأحمال العمل العلمية والبيانات الكثيفة

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

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

يتم إنشاء بيئة Conda باستخدام conda create --name my-envإضافة اختيارية python=3.11 أو باقات محددة مثل numpy or pandas على نفس سطر الأوامر. ستقوم Conda بحل التبعيات، وتنزيل الإصدارات المناسبة لمنصتك، ووضعها في دليل بيئة معزول تديره Conda نفسها.

تتم معالجة التنشيط وإلغاء التنشيط بواسطة conda activate my-env و conda deactivate. بمجرد التفعيل، يتم تثبيت الحزم باستخدام conda install يستخدم مستودعات Conda، التي غالبًا ما توفر ملفات تنفيذية محسّنة. في العديد من سير العمل، يتم دمج Conda مع المكتبات العلمية الضخمة و pip بالنسبة للاعتمادات العامة الخاصة بلغة بايثون فقط، قم بتثبيت حزم Conda أولاً ثم حزم pip بعد ذلك لتقليل التعارضات.

يتألق برنامج Conda أيضًا عندما تحتاج إلى تصدير واستنساخ بيئات كاملة. مع conda env export > environment.yml لا يقتصر الأمر على التقاط حزم بايثون فحسب، بل يشمل أيضًا البيانات الوصفية مثل النظام الأساسي والقنوات. على جهاز آخر، conda env create -f environment.yml يُنشئ بيئة متطابقة، وهو أمر رائع لإمكانية تكرار الأبحاث والمشاريع التعاونية.

مديرو المشاريع المعاصرون: pip + venv مقابل Pipenv و Poetry و pdm و uv

بمرور الوقت، تطور النظام البيئي لـ Python من "pip + virtualenv + requirements.txt" إلى أدوات أكثر تحديدًا توحد إدارة التبعيات والبيئات والتغليف. على الرغم من أن الثلاثي الكلاسيكي لا يزال يعمل بشكل جيد، إلا أن العديد من الفرق تفضل الآن سير العمل المتكامل.

تعتمد الترتيبات التقليدية على pip و virtualenv or venv، مع صناعة يدوية requirements.txt ملف. تقوم بإنشاء بيئة افتراضية يدويًا، وتفعيلها، وتثبيت التبعيات، وصيانة منطق التجميد والترقية الخاص بك. هذا الأسلوب مرن للغاية، ولكنه أيضًا عرضة لسوء التكوين إذا لم تكن الفرق منضبطة.

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

Poetry ويتجاوز ذلك من خلال تقديم مدير مشروع كامل يتولى إدارة التبعيات وعمليات البناء والنشر في أداة واحدة. يعتمد على الحديث pyproject.toml المعيار (PEP 621) ويكتب poetry.lock ملف بتنسيق TOML. يتميز Poetry بقدرته على حل التبعيات بكفاءة، ويدعم قيود الإصدار بسلاسة، ويجعل النشر على PyPI أمرًا بسيطًا باستخدام أوامر مثل poetry publish.

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

في الآونة الأخيرة، uv ظهرت كأداة موحدة عالية الأداء تهدف إلى أن تكون مثل Cargo للغة Python. يقدم نفسه على أنه ملف تنفيذي واحد مكتوب بلغة Rust يجمع بين قدرات متعددة: حل التبعيات، وإدارة البيئة، وتثبيت إصدار Python، وتنفيذ البرامج النصية، والقفل، والبناء والنشر.

ما الذي يميز مكتبة uv لبيئات بايثون الموحدة؟

uv تم تصميمه ليحل محل العديد من الأدوات المنفصلة من خلال توفير سير عمل متكامل وسريع للغاية. تُظهر المعايير من المشروع أنه أسرع بحوالي 8-10 مرات من pip و pip-tools بدون ذاكرة تخزين مؤقتة، وأسرع بحوالي 80-115 مرة عند استخدام ذاكرة التخزين المؤقت، مما يجعل مزامنة البيئات أو إعادة إنشائها تبدو فورية تقريبًا.

في جوهرها، توفر uv واجهة برمجة تطبيقات للمشروع تتعامل مع إدارة التبعيات، وإنشاء البيئة، وملفات القفل، وتنفيذ الأدوات. أوامر مثل uv init إنشاء مشروع جديد بهيكل أساسي: أ pyproject.tomlأو المعلم .python-version ملف وبداية main.pyوهذا يمنحك تصميمًا متناسقًا مع عدم وجود إعداد يدوي تقريبًا.

عندما تقوم بتشغيل uv add some-package، يقوم برنامج uv تلقائيًا بإنشاء .venv البيئة (إذا لزم الأمر)، التحديثات pyproject.toml ويكتب uv.lock ملف. يسجل ملف القفل الإصدارات والقيم الجزئية المُحَلَّلة بدقة لكل تبعية، مما يضمن إمكانية إعادة تثبيت البرنامج. على عكس العديد من الأدوات الأخرى، uv.lock وهو متعدد المنصات بشكل صريح، لذا يمكن استخدام نفس الملف على أنظمة Linux وWindows وmacOS مع ضمان الحصول على نتائج حتمية.

ميزة أخرى قوية هي uv run، والذي يقوم بتشغيل الأوامر في بيئة المشروع دون الحاجة إلى تفعيله يدويًا أولاً. قبل التنفيذ، يتأكد uv من أن البيئة تتطابق مع البيئة الحالية pyproject.toml و uv.lockوبالتالي، لن تقوم بتشغيل التعليمات البرمجية عن طريق الخطأ مع تبعيات قديمة. هذا يقلل من احتكاك التكرار uv sync or uv lock المكالمات.

يُتيح برنامج uv استخدام أدوات سطر الأوامر بشكل مؤقت وسريع. uvx و uv tool run. تتيح لك هذه الأوامر تشغيل واجهات سطر الأوامر مثل black, pytest or pyinstaller دون إضافتها بشكل دائم كاعتمادات للمشروع. وهي مفيدة بشكل خاص في مسارات التكامل المستمر أو البرامج النصية حيث تحتاج إلى أداة لفترة وجيزة.

نظرة معمقة على وضع pip الخاص بـ uv وتكوينه

يتمثل أحد أهداف تصميم uv في أن يكون ترقية سهلة الاستخدام للعديد من سير عمل pip. بالنسبة للعمليات الشائعة، يمكنك حرفيًا التبديل pip install لـ uv pip install أو استخدام uv pip sync لمحاكاة ملف المتطلبات. في العديد من المشاريع القائمة، يجعل هذا الأمر عملية التبني بسيطة ومنخفضة المخاطر.

ومع ذلك، فإن uv ليس نسخة مثالية من pip عن قصد، والعديد من الاختلافات هي تحسينات متعمدة. على سبيل المثال، لا يقرأ برنامج uv ملفات تكوين pip مثل pip.conf or PIP_INDEX_URLبدلاً من ذلك، يستخدم متغيرات بيئته الخاصة مثل UV_INDEX_URL ويخزن التكوين تحت uv.toml أو في [tool.uv.pip] قسم من pyproject.tomlوهذا يقلل من الاقتران العرضي بدلالات pip المتطورة.

يُعد تحديد أولويات الفهرس مجالًا آخر تُشدد فيه uv الأمان بشكل افتراضي. للحماية من هجمات التباس التبعيات، يُفضّل uv فهارس الحزم الداخلية على PyPI عندما يُوفّر كلاهما حزمةً بنفس الاسم افتراضيًا. يوجد مُعلّم --index-strategy لتعديل هذا السلوك، لكن الإعداد الافتراضي الآمن يساعد على تجنب مشكلات سلسلة التوريد الدقيقة في إعدادات الشركات.

على عكس pip، تم تصميم uv حول البيئات الافتراضية كهدف افتراضي لعمليات التثبيت. أوامر مثل uv pip install و uv pip sync سيتم تثبيته في البيئة النشطة حاليًا أو اكتشافه تلقائيًا .venv يُوضع الدليل في المجلد الحالي أو المجلد الأصل. هذا يُبعدك عن التثبيتات العامة ويُقربك من عزل كل مشروع على حدة بشكل افتراضي.

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

ملفات القفل، والتصدير، والتبعيات متعددة المصادر باستخدام uv

استخدم uv.lock يُعد الملف أساسيًا في قصة قابلية تكرار الأشعة فوق البنفسجية. هو مستند TOML يحتوي على جميع الحزم المُحلَّلة، والإصدارات الدقيقة، وسجلات المصادر، والتجزئات، وعناوين URL للتنزيل، والأحجام، والطوابع الزمنية للتحميل. على عكس pyproject.tomlوالتي تعبر عن نطاقات الإصدارات والغرض (على سبيل المثال requests >= 2.30يصف ملف القفل مجموعة العناصر الدقيقة التي يجب تثبيتها.

يشجعك برنامج Uv على إضافة ملف القفل إلى نظام التحكم في الإصدارات. وبهذه الطريقة، يمكن لأي مطور أو مهمة تكامل مستمر تشغيلها uv sync or uv pip install وفقًا لملف القفل، يحصل البرنامج على نفس مجموعة التبعيات تمامًا، عبر جميع أنظمة التشغيل المدعومة. وهذا يزيد بشكل كبير من الثقة عند طرح إصدارات جديدة.

إذا كنت بحاجة إلى التوافق مع الأدوات التقليدية، فيمكن لبرنامج uv تصدير تنسيقات أخرى من ملف القفل الخاص به. استخدام أوامر مثل uv export --format requirements.txt or uv export --format pylock.tomlيمكنك إنشاء كلاسيكي requirements.txt ملفات أو معيارية pylock.toml وهذا ما تفهمه الأدوات الأخرى. وهذا يجعل الانتقال التدريجي من أنظمة العمل القديمة أكثر سلاسة.

ومن القدرات المتقدمة الأخرى لـ uv قدرتها على التعامل بمرونة مع المؤشرات والمصادر المتعددة. In pyproject.toml يمكنك تحديد عدة [[tool.uv.index]] على سبيل المثال، إدخالات مثل مرآة PyPI، أو فهرس PyTorch wheel لعمليات بناء GPU، أو سجل حزم داخلي، ثم ربط تبعيات محددة بهذه المصادر تحت [tool.uv.sources].

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

بناء ونشر وتشغيل الأدوات باستخدام uv

بالإضافة إلى إدارة التبعيات، يتولى uv أيضًا بناء ونشر حزم بايثون. لاستخدام uv كخلفية بناء، pyproject.toml يحتاج الى [build-system] القسم المشار إليه uv_build، على سبيل المثال: requires = ["uv_build >= 0.7.13, < 0.8"] و build-backend = "uv_build"يمكنك إعداد ذلك عند بدء تشغيل المشروع باستخدام uv init --build-backend uv.

بعد التكوين، التشغيل uv build يخلق dist/ دليل يحتوي على ملفات المصدر وتوزيعات العجلات الخاصة بك. هذه الملفات جاهزة للتحميل إلى الفهرس أو السجل الداخلي الذي اخترته. لا يقوم Uv بنشرها تلقائيًا؛ فعمليتا البناء والنشر منفصلتان للحفاظ على التحكم واضحًا.

للنشر، أضف تكوين الفهرس ضمن [[tool.uv.index]] مع publish-urlوغالباً ما تشير إلى نقطة نهاية التحميل الخاصة بـ PyPI. على سبيل المثال، يمكنك تعريف فهرس باسم pypi مع url = "https://pypi.org/simple/" و publish-url = "https://upload.pypi.org/legacy/". ثم uv publish سيقوم بدفع توزيعاتك المبنية إلى هناك، على غرار استخدام twine لكنها مدمجة في نفس الأداة.

كما تعمل Uv على تبسيط العمل مع أدوات سطر الأوامر من خلال uvx و uv tool run. بدلاً من تثبيت أدوات مثل pytest, black or pyinstaller يمكنك تثبيتها بشكل دائم في بيئتك، واستدعاؤها عند الحاجة. يُعد هذا مفيدًا بشكل خاص لمهام التكامل المستمر أو المهام المؤقتة التي ترغب فيها بتقليل تبعيات المشروع إلى الحد الأدنى مع الاستمرار في الوصول إلى نظام أدوات متكامل وغني.

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

دمج بيئات العمل مع بيئات التطوير المتكاملة (IDEs) ودفاتر الملاحظات وسير العمل

إن امتلاك بيئات قوية ليس سوى نصف القصة - يجب أن يستخدمها المحرر والأدوات الخاصة بك بالفعل. تتمتع بيئات التطوير المتكاملة الشائعة مثل VS Code و PyCharm بدعم من الدرجة الأولى لاكتشاف البيئات الافتراضية والعمل معها، ويمكن لـ Jupyter تسجيلها كنوى منفصلة.

في VS Code، عادةً ما تسمح لملحق بايثون بالاكتشاف التلقائي .venv المجلدات الموجودة في شجرة مشروعك. بعد ذلك، يمكنك اختيار المفسر المناسب من خلال "Python: تحديد المفسر" في لوحة الأوامر. بمجرد اختياره، يستخدم VS Code هذه البيئة لميزات الطرفية والمصحح اللغوي المدمجة، ويقوم بتنشيطها تلقائيًا عند فتح نوافذ طرفية جديدة.

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

بالنسبة لدفاتر Jupyter، فإن الخطوة الرئيسية هي التثبيت ipykernel في بيئتك وتسجيلها كنواة. بعد تشغيل شيء مثل python -m ipykernel install --user --name myenvستظهر بيئتك باسم "myenv" في قائمة نواة Jupyter. هذا يُسهّل مزامنة دفاتر الملاحظات مع بيئة المشروع المقابلة، مما يجنّبك أي اختلافات طفيفة.

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

الأخطاء الشائعة وأفضل الممارسات للبيئات الموحدة

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

إذا انتهى بك الأمر ببيئة تحتوي على إصدار بايثون خاطئ، فإن الحل هو إعادة إنشائها بشكل صريح باستخدام المفسر الصحيح. على سبيل المثال، python3.11 -m venv .venv or virtualenv --python=/usr/bin/python3.11 .venv يضمن ذلك تضمين وقت التشغيل المناسب في البيئة. على الأنظمة التي تستخدم pyenvيمكنك أولاً تحديد إصدار محلي من بايثون ثم إنشاء بيئتك فوق ذلك.

عندما تبدو نصوص التفعيل مفقودة أو معطلة، فهذا يعني غالبًا أن البيئة لم يتم إنشاؤها بشكل صحيح. حذف المجلد وإعادة إنشائه بالصيغة المناسبة python -m venv or virtualenv عادةً ما يحل هذا الأمر المشكلة. في نظام ويندوز، إذا كان PowerShell يمنع التنشيط، فقد تحتاج إلى تخفيف سياسة التنفيذ للمستخدم الحالي.

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

تساهم الممارسات الصحية الجيدة المتعلقة بتسمية الملفات والتحكم في الإصدارات بشكل كبير في توفير بيئات قابلة للصيانة. استخدم أسماءً واضحة ومتسقة للبيئات، وفضّل بيئة واحدة لكل مشروع، ولا تقم أبدًا بتثبيت دليل البيئة نفسه. بدلاً من ذلك، أضف إدخالات مثل .venv/ or venv/ لديك .gitignore والاعتماد على ملفات القفل وملفات المتطلبات لإعادة بناء البيئات عند الطلب.

وأخيرًا، فإن توثيق كيفية إنشاء وتحديث البيئات في قسم README قصير يوفر عليك وعلى زملائك في الفريق الكثير من التخمين في المستقبل. مقتطف بسيط من سطرين - على سبيل المثال، python -m venv .venv تليها pip install -r requirements.txt or uv sync - يمكن أن يجعل عملية الإعداد أكثر سلاسة ويحافظ على استراتيجية بيئة بايثون الموحدة متسقة عبر الفريق.

من خلال الجمع بين الأدوات الكلاسيكية مثل venv و virtualenv و pip و Conda مع المديرين الحديثين مثل Poetry و pdm و uv، يمكنك تصميم سير عمل بيئة موحد سريع وقابل للتكرار وآمن. يحصل كل مشروع على عالمه المعزول الخاص به، وتضمن ملفات القفل عمليات تثبيت متسقة، وتتكامل بيئات التطوير المتكاملة ودفاتر الملاحظات بسلاسة، وتقوم أدوات عالية الأداء مثل uv بربط كل شيء معًا تحت سقف واحد، مما يحول ما كان في السابق مجموعة فوضوية من البرامج النصية إلى أساس متماسك وموثوق لتطوير بايثون الجاد.