لماذا البيئات الافتراضية؟

إن تساءلت يومًا: «لماذا أحتاج إلى python3 -m venv venv؟» — فهذه الصفحة تشرح لك السبب.

المشكلة

تخيّل أن لديك مشروعين بلغة Python:

• المشروع أ: يحتاج إلى Flask الإصدار 2.0
• المشروع ب: يحتاج إلى Flask الإصدار 3.0

بدون البيئات الافتراضية، يثبّت Python الحزم على مستوى النظام كله. وتثبيت Flask 3.0 من شأنه أن يُعطّل المشروع أ.

الحل

يحصل كل مشروع على بيئة معزولة خاصة به، بحزمها الخاصة:

System Python
├── Project A (venv) → Flask 2.0
├── Project B (venv) → Flask 3.0
└── Other projects (no venv) → whatever system has

كيف يعمل ذلك

# أنشئ بيئة افتراضية
python3 -m venv venv

# فعّلها
source venv/bin/activate      # macOS/Linux
venv\Scripts\activate         # Windows

# الآن تذهب عمليات التثبيت عبر pip إلى venv/، لا إلى النظام كله
pip install flask

# عند الانتهاء، عطّل البيئة
deactivate

بعد التفعيل، تعرض طرفيتك (venv) في سطر الأوامر — تذكيرًا بصريًا.

ماذا يوجد داخل بيئة افتراضية؟

venv/
├── bin/          # ملف Python التنفيذي + السكربتات
├── lib/          # الحزم المثبّتة تُخزَّن هنا
└── pyvenv.cfg    # يشير إلى Python النظام الذي أُنشئت منه

عند التفعيل، يشغّل python3 النسخة الموجودة داخل venv/bin/، ولا يرى إلا الحزم المثبّتة في venv/lib/.

قاعدة .gitignore

لا تعمل commit لبيئتك الافتراضية أبدًا. أضفها إلى .gitignore:

echo "venv/" >> .gitignore

يعيد المطورون الآخرون إنشاءها من requirements.txt:

python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

تشبيه سريع

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