तपाई किन र कसरी भर्चुअल वातावरण प्रयोग गर्नुहुन्छ?

Question

Accepted Answer

A **virtual environment** एक अलग्गै Python वातावरण हो आफ्नो स्थापित गरिएको प्याकेजहरूसँग, सिस्टम Python र अन्य प्रोजेक्टहरूबाट अलग। यो **dependency conflicts** समाधान गर्दछ — विभिन्न प्रोजेक्टहरूले एक ही प्याकेजको विभिन्न (यहाँ सम्म कि असंगत) संस्करणहरू प्रयोग गर्न सक्छन्।

## समस्या जो यो समाधान गर्दछ

```text
Project A needs Django 3.2
Project B needs Django 4.2
→ Installing globally, they CONFLICT — you can't have both versions system-wide.
Virtual environments give each project its OWN isolated set of packages.
```

अलगलीकरणबिना, प्याकेजहरू विश्वव्यापी रूपमा स्थापन गर्नुले प्रोजेक्टहरू बीच संस्करण द्वन्द्व को नेतृत्व गर्दछ र सिस्टम उपकरणहरूलाई हानि पुर्याउन सक्छ जो विशेष संस्करणहरू मा निर्भर गर्दछ।

## एक सृजना गर्नु र प्रयोग गर्नु (built-in venv)

```bash
# 1. create a virtual environment (a folder named .venv)
python -m venv .venv

# 2. ACTIVATE it (shell-specific)
source .venv/bin/activate      # macOS/Linux
.venv\Scripts\activate         # Windows

# 3. now pip installs go INTO this env, isolated from the system
pip install django requests

# 4. when done
deactivate
```

एक पटक सक्रिय भएपछी, `python` र `pip` पर्यावरणको अलग गरिएको प्रतिलिपिलाई सन्दर्भ दिन्छ — प्याकेजहरू सिर्फ त्यहाँ स्थापन हुन्छ, प्रणाली-व्यापक नहीं।

## आश्रितहरू क्याप्चर र पुनरुत्पादन गर्नु

```bash
pip freeze > requirements.txt       # record exact installed versions
pip install -r requirements.txt     # recreate the env elsewhere (teammate, CI, prod)
```

A `requirements.txt` पर्यावरणलाई **reproducible** बनाउँछ — जो कोई पनि बिल्कुल एक जस्तै आश्रितहरू पुनः बनाउन सक्छ, "मेरो मेसिनमा काम गर्दछ" समस्याहरू रोकिन्छ।

## आधुनिक उपकरणहरू

```text
venv + pip      → built-in, standard, widely used
poetry          → dependency management + lockfile + packaging (popular)
pipenv          → combines pip + venv with a lockfile
uv / pdm        → newer, faster tools
conda           → common in data science (manages Python versions + non-Python deps too)
```

नयाँ उपकरणहरू (poetry, uv) lockfiles र राम्रो आश्रितता समाधान थप्छन्, तर मूल अवधारणा — प्रति-प्रोजेक्ट अलग गरिएको पर्यावरण — समान छ।

## सधैं संस्करण नियन्त्रणबाट env बाहिर राख्नुहोस्

```text
# .gitignore
.venv/        ← don't commit the environment; commit requirements.txt/lockfile instead
```

## यो किन महत्वपूर्ण छ

भर्चुअल पर्यावरणहरू कुनै पनि Python प्रोजेक्टको लागि आवश्यक, मानक अभ्यास हो — तिनीहरूले प्रोजेक्टहरू बीच र प्रोजेक्टहरू र सिस्टम Python बीचमा आश्रितता द्वन्द्वहरू रोक्छ, र (`requirements.txt`/lockfiles सँग) मेसिनहरू, सहकर्मीहरू, CI, र उत्पादनमा पर्यावरणहरू पुनरुत्पादन योग्य बनाउँछ।

तिनीहरूलाई छोडेर संस्करण द्वन्द्वहरू, टूटेको सिस्टम उपकरणहरू, र अपुनरुत्पादन योग्य सेटअपहरूको कारण हुन्छ।

कसरी पर्यावरणहरू सृजना गर्नु, सक्रिय गर्नु, र आश्रितहरू क्याप्चर गर्नु भन्ने कुरा बुझ्नु — र आधुनिक उपकरण परिदृश्य (poetry, uv) — पेशेवर Python विकासको लागि मौलिक र कुनै पनि वास्तविक प्रोजेक्टमा आधारभूत अपेक्षा हो।