3.2pip والبيئات الافتراضية (venv) وتدبير الاعتماديات
الأساسي في 30 ثانية
- العمومي يخلط كل شيء : مشروعان يتطلبان إصدارين من حزمة واحدة مستحيلان معا — كل مشروع يستحق بيئة معزولة.
- طقس venv + pip : python -m venv .venv، والتفعيل، وpip install، وpip freeze > requirements.txt — المفسر وpip يشيران حينها إلى venv.
- مجلد .venv لا يُلتزَم به أبدا، وrequirements دائما : إصدارات مثبتة، وإعادة بناء مثبتة عبر pip install -r — المشروع محمول.
حالة مصغرة متسلسلة — نبيل يخرج من جحيم الإصدارات
نبيل، محلل بيانات مبتدئ في الجزائر، يثبت كل شيء عموميا : يتطلب تحليل المبيعات إصدارا حديثا من مكتبة، لكن تقرير زميل ينكسر متى حدث. أنشأ venv لكل مشروع (python -m venv .venv)، وفعل، وثبت، وجمد بـ pip freeze > requirements.txt، وأضاف .venv إلى .gitignore. محذوفا ثم معادا بناؤه عبر pip install -r، استعاد كل مشروع إصداراته بدقة.
هذه الحالة نفسها تعود في الدرس والمخطط والنص الجاهز وتحدي 48 ساعة.
1. فوضى العمومي وفقاعة venv
قوة بايثون فهرسها PyPI، المثبت عبر pip (pip install pandas). لكن تثبيت كل شيء عموميا يخلط اعتماديات كل المشاريع : يتطلب المشروع A إصدارا، وB آخر — مستحيل معا، إنه جحيم الاعتماديات. منذ المشروع الثاني، يصبح العزل غير قابل للتفاوض.
الحل هو البيئة الافتراضية (venv) : مجلد معزول ببايثونه وحزمه، دون مساس بالمشاريع الأخرى. ننشئها (python -m venv .venv)، ونفعلها (Windows : .venv\Scripts\activate ؛ macOS/Linux : source .venv/bin/activate) — يتغير الموجه، ويشير python وpip حينها إلى venv. أنشأ نبيل venv لتحليل المبيعات، وآخر لإعداد التقارير : كل واحد يعيش حياته.
2. التجميد والمشاركة وإعادة البناء : requirements.txt
venv وحده لا يكفي : يلزم عقد الإصدارات. يصدر pip freeze > requirements.txt الاعتماديات والإصدارات المثبتة ؛ ويعيد pip install -r requirements.txt تثبيتها بعينها في مكان آخر. مجلد .venv لا يُلتزَم به أبدا (ضخم، خاص بالجهاز، عبر .gitignore) ؛ وrequirements.txt دائما (خفيف، قابل للمشاركة).
اختبار الحقيقة عند نبيل : حذف .venv وإعادة بنائه بأمر واحد — إذا اشتغل التحليل، فالمشروع محمول. تحقق بـ pip list أن المكتبة في venv هذا فعلا، واختر مفسر .venv في المحرر. وبعد كل إضافة، أعد التجميد لإبقاء العقد محينا.
🔎 مثال ملموس — الطقس الكامل للمشروع المعزول
يعزل نبيل تحليل مبيعاته، ثم يعيد بناءه في مكان آخر.
python -m venv .venv
.venv\Scripts\activate
pip install requests
pip freeze > requirements.txt
deactivateالقراءة : أنشئ، وفعل، وثبت، وجمد — يصبح requirements هو العقد.
الدرس : في مكان آخر، أعد إنشاء venv ثم pip install -r requirements.txt يعيد بعينه.
مفردات القسم
- pip
- مدير حزم بايثون : pip install requests يحمل مكتبة ويثبتها من PyPI في البيئة النشطة.
مثال بسيط: عبارة pip install requests لنبيل في venv التحليل.
ما ليس كذلك: تحميل ZIP ووضعه يدويا.
رد فعل: تحقق دائما من venv النشط قبل pip install.
- PyPI
- المستودع المركزي للمكتبات الطرف الثالث في بايثون : مئات الآلاف من الحزم القابلة للتثبيت.
مثال بسيط: الفهرس حيث يجد نبيل requests و pandas.
ما ليس كذلك: المكتبة المعيارية المرفقة أصلا.
رد فعل: المعيارية أولا، وPyPI بعدها.
- البيئة الافتراضية (venv)
- مجلد معزول ببايثونه وحزمه، خاص بمشروع، دون تداخل مع غيره.
مثال بسيط: مجلد .venv لتحليل-مبيعات نبيل، منفصل عن إعداد التقارير.
ما ليس كذلك: تثبيت عمومي مشترك لكل المشاريع.
رد فعل: venv لكل مشروع، منذ البداية.
- التفعيل
- جعل venv نشطا في الطرفية ليشير إليه python و pip (موجه معدل).
مثال بسيط: تفعيل نبيل قبل كل جلسة تحليل.
ما ليس كذلك: العمل ناسيا التفعيل، أي عموميا.
رد فعل: فعل أولا، وثبت بعدها.
- requirements.txt
- قائمة الاعتماديات والإصدارات : يصدرها pip freeze، ويعيد pip install -r تثبيتها بعينها.
مثال بسيط: العقد المنسخ الذي يشاركه نبيل في الجزائر.
ما ليس كذلك: مجلد .venv الملتزَم به في Git.
رد فعل: جمد بعد كل إضافة، وأعد البناء للإثبات.
في التطبيق — عزل مشروع بـ venv و pip
- أنشئوا venv (python -m venv .venv) ثم فعلوه ؛ وتحققوا أن موجه الطرفية تغير.
- ثبتوا مكتبة (pip install requests) وتحققوا بـ pip list أنها في venv هذا، لا عموميا.
- جمدوا بـ pip freeze > requirements.txt ؛ وافتحوا الملف ولاحظوا الإصدارات المثبتة.
- عطلوا (deactivate)، واحذفوا venv، وأعيدوا إنشاءه وأعيدوا التثبيت عبر pip install -r requirements.txt.
نص جاهز للقول — عرض بيئته (30 ثانية)
« لكل مشروع venv خاصه : منشأ عبر python -m venv .venv، ومفعل قبل أي تثبيت، والاعتماديات مجمدة عبر pip freeze في requirements.txt منسخ، و.venv متجاهَل عبر Git. مختبَر بالحذف ثم pip install -r : إعادة بناء بعينها. »
يُقال في المراجعة ؛ ويُعرَض الموجه المفعل وrequirements.
نموذج نسخ-لصق — طقس venv + requirements
python -m venv .venv
.venv\Scripts\activate
pip install requests
pip list
pip freeze > requirements.txt
deactivate
python -m venv .venv
.venv\Scripts\activate
pip install -r requirements.txtمستقل
يكفي venv + requirements مجمد لمشاركة التحليل دون احتكاك.
مقاولة صغيرة في الجزائر
يكرر نبيل الطقس : venv للمبيعات، وvenv لإعداد التقارير، وصفر تعارض.
فريق منتج
فرض .venv متجاهَل + requirements منسخ لتثبيتات متطابقة في كل مكان.
مبتدئ
هذا الأسبوع : venv واحد، وتثبيت واحد، وتجميد واحد، وإعادة بناء واحدة.
✓ ممارسات جيدة
- إنشاء venv لكل مشروع منذ أول pip install.
- التجميد بعد كل إضافة (freeze) وإبقاء requirements منسخا.
- إعادة البناء (حذف + install -r) لإثبات قابلية إعادة الإنتاج.
✗ أخطاء شائعة
- تثبيت كل شيء عموميا (تعارضات إصدارات مضمونة).
- الالتزام بـ .venv (ميغابايت عديمة الفائدة، خاصة بالجهاز).
- مشاركة requirements دون إصدارات مثبتة (انحراف صامت).
النقاط الأساسية
- pip يثبت من PyPI في البيئة النشطة — تحقق من التفعيل أولا.
- venv يعزل الاعتماديات لكل مشروع : انتهت تعارضات الإصدارات.
- requirements.txt (freeze / install -r) يجعل المشروع قابلا لإعادة الإنتاج في كل مكان.
- .venv لا يُلتزَم به أبدا (.gitignore) ؛ وrequirements يُنسَخ دائما، ويُعاد بناؤه للإثبات.
تحدي 48 ساعة — طبّق غدا
أنشئوا venv واحدا، وثبتوا حزمة واحدة، وجمدوا requirements، ثم أعيدوا البناء عبر install -r.
- لكل مشروع venv مفعل قبل التثبيت.
- requirements عندي يجمد الإصدارات الدقيقة.
- .venv عندي متجاهَل، وإعادة البناء تنجح.
أسئلة شائعة
لماذا لا نثبت كل شيء عموميا، فهو أبسط ؟
لأن مشروعين سيتطلبان سريعا إصدارين متعارضين من مكتبة واحدة : إنه جحيم الاعتماديات. venv لكل مشروع يعطي كل واحد ما يلزمه بالضبط ويجعل المشروع قابلا للمشاركة بعينه عبر requirements.txt.
هل نلتزم بمجلد .venv في Git ؟
لا، أبدا : ضخم وخاص بالجهاز. نستبعده عبر .gitignore ولا نشارك سوى requirements.txt — يعيد كل متعاون إنشاء venv عبر pip install -r.
ماذا نشارك في Git لإعادة إنتاج البيئة ؟