რატომ და როგორ იყენებთ ვირტუალურ გარემოს?

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.
```

იზოლაციის გარეშე, პაკეტების გლობალური ინსტალაციამ იწვევს ვერსიის კონფლიქტებს პროექტებს შორის და შეიძლება დაზიანდეს სისტემის ინსტრუმენტები, რომლებიც নির্ভর করেს კონკრეტული ვერსიებზე।

## ერთის შექმნა და გამოყენება (ჩაშენებული 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-ის მეშვეობით) გარემოები გახდება reproducible მანქანებში, თანამშრომელში, CI-ში და წარმოებაში.

მათ გავლენის რეშება იწვევს ვერსიის კონფლიქტებს, დაზიანებული სისტემის ხელსაწყოებს და არააღწერვადი კონფიგურაციას.

გაგება თუ როგორ შევქმნათ, შევაქტივირებთ და დავჭერთ დამოკიდებულებებს — და თანამედროვე ხელსაწყოების ლანდშაფტი (poetry, uv) — არის ფუნდამენტური Python-ის პროფესიული განვითარებისთვის და ძირითადი მოთხოვნილება ნებისმიერ რეალურ პროექტში.