Bayangkan dua proyek berjalan di satu komputer: proyek lama butuh Django 4.2, proyek baru membutuhkan Django 5.1. Jika keduanya memasang package ke Python global, hanya satu yang bisa menang — site-packages hanya punya satu slot untuk django. Virtual environment (venv) menyelesaikan masalah ini dengan memberi setiap proyek folder site-packages sendiri. Pada chapter ini kita membuat venv pertama kita dan membedah isi folder tersebut.

Masalah Tanpa Isolasi #

Memasang seluruh dependency ke Python global terasa mudah di awal, tetapi cepat menimbulkan masalah:

  • Konflik versi: dua proyek membutuhkan versi berbeda dari distribution yang sama; salah satunya pasti rusak.
  • Pencemaran: site-packages global menumpuk puluhan package dari proyek yang bahkan sudah terhapus, dan tidak ada cara membedakan mana yang masih terpakai.
  • Tidak reproducible: tidak ada daftar resmi package yang dibutuhkan proyek; memindahkan proyek ke komputer lain menjadi tebak-tebakan.
  • Izin sistem: memasang package ke area sistem di Linux/macOS memancing praktik berbahaya sudo pip install.

Membuat venv Pertama #

Python membawa solusinya di standard library: module venv. Masuk ke folder proyek, lalu jalankan satu perintah:

bash 
cd proyek-toko
python3 -m venv .venv

Perintah ini tidak mencetak apa pun. Diamnya perintah berarti sukses — folder .venv kini berada di akar proyek. Mari kita bedah perintahnya:

  1. python3 -m venv: flag -m menjalankan module venv bawaan interpreter Python — tidak ada yang perlu dipasang terlebih dahulu.
  2. .venv: argumen posisi menentukan lokasi folder environment. Nama .venv adalah konvensi komunitas; titik di depan membuat folder tersembunyi di Linux/macOS.

Venv bukan salinan penuh instalasi Python. Module venv hanya membuat struktur ramping yang menunjuk kembali ke interpreter asli:

text 
.venv/
├── bin/
│   ├── activate
│   ├── activate.csh
│   ├── activate.fish
│   ├── Activate.ps1
│   ├── pip
│   ├── pip3
│   ├── python -> python3.12
│   ├── python3 -> python3.12
│   └── python3.12
├── include/
├── lib/
│   └── python3.12/
│       └── site-packages/
│           ├── pip/
│           └── pip-25.0.1.dist-info/
├── lib64 -> lib
└── pyvenv.cfg

Struktur di atas diambil dari venv asli yang dibuat dengan Python 3.12 di Linux. Di Windows, nama foldernya sedikit berbeda: bin menjadi Scripts (berisi python.exe dan pip.exe), lib menjadi Lib, dan symlink lib64 tidak ada.

Peran Setiap Komponen #

bin dan site-packages #

Rantai python -> python3.12 di folder bin adalah symlink menuju interpreter basis yang membuat venv tadi. Inilah alasan membuat venv cepat dan hemat ruang: interpreter tidak disalin, hanya dirujuk. Folder lib/python3.12/site-packages adalah tujuan semua pip install saat venv aktif — di sinilah package pip bawaan itu berada.

pyvenv.cfg #

Berkas kecil pyvenv.cfg adalah identitas venv. Tiga baris utamanya tampak seperti ini (jalur home akan berbeda di komputer Anda; beberapa instalasi juga menambahkan baris lain seperti executable dan command):

text 
home = /usr/local/bin
include-system-site-packages = false
version = 3.12.15
  1. home: lokasi interpreter Python yang menjadi dasar venv.
  2. include-system-site-packages = false: kunci utama isolasi — site-packages global tidak terlihat dari dalam venv, sehingga package global tidak bisa diimpor dan tidak bisa bertabrakan.
  3. version: versi Python basis yang dipakai, dalam hal ini 3.12.15.

Aturan Satu venv per Proyek #

Venv murah, jadi tidak ada alasan berbagi. Tiga aturan praktis berikut menjaga proyek tetap sehat:

  • Satu proyek, satu venv, dibuat di akar proyek dengan nama .venv agar tool seperti VS Code mengenalinya secara otomatis.
  • Jangan pernah commit .venv ke version control. Tambahkan .venv/ ke .gitignore; environment mudah dibuat ulang dari daftar dependency, bukan disimpan mentah-mentah.
  • Jangan memindahkan folder venv. Isi pyvenv.cfg dan symlink di dalamnya menyimpan jalur absolut; memindah atau mengganti nama folder proyek membuat venv rusak. Buat ulang venv baru bila perlu.