Kenapa ada Virtual Environments?
Sebelum mulai, kita perlu pahami masalah yang ingin diselesaikan oleh Virtual Environments.
Ketika menginstall Python package secara global (tanpa virtual environment), instalasi Python package itu ditempatkan di direktori Python sistem. Sekarang bayangkan jika:
- Project A menggunakan
Django==4.2 - Project B menggunakan
Django==5.1
Kita tidak bisa memiliki kedua versi yang diinstal secara global pada saat yang bersamaan. Salah satu akan menimpa yang lain. Virtual environments mengatasi ini dengan memberikan setiap project instalasi Python dan direktori paket yang isolated / terisolasi.
Server Kita
├── System Python (global)
│ └── site-packages/ ← dibagikan, rawan konflik
│
└── Projects/
├── project-a/
│ └── .venv/
│ └── site-packages/ ← Django 4.2 berada di sini
└── project-b/
└── .venv/
└── site-packages/ ← Django 5.1 berada di sini
Langkah 1: Buat Virtual Environment
Masuk ke folder project kita dan jalankan:
| |
Yang terjadi di sini adalah:
python3 -m venvmenjalankan modulvenvyang sudah terpasang dalam library standar Python.venvadalah nama folder yang akan menyimpan environment terisolasi (awalan titik menyembunyikannya sesuai conventiont)
Struktur folder kita sekarang terlihat seperti:
my-drf-project/
└── .venv/
├── bin/ ← file executable (python, pip, dll.) di Linux/Mac
├── lib/ ← site-packages terisolasi
└── pyvenv.cfg ← metadata tentang environment
Di Windows, bin/ disebut Scripts/.
Langkah 2: Aktivasi Virtual Environment
| |
Setelah aktivasi, prompt terminal kita menjadi:
| |
Awalan (.venv) menandakan bahwa environment telah aktif. Sekarang perintah python atau pip apa pun menggunakan isolated environment, bukan Python yang ada di sistem.
Kita dapat verifikasi dengan cara:
| |
Langkah 3: Install Django dan DRF
Pada virtual environment:
| |
Yang diinstall adalah:
django- framework webdjangorestframework- DRF, yang berdiri di atas Django
Untuk memverifikasi:
| |
Langkah 4: Buat dan Kelola requirements.txt
requirements.txt adalah file teks biasa yang berisi setiap paket yang project kita butuhkan beserta versi spefisiknya. File ini berfungsi sebagai blueprint yang dapat direproduksi sehingga siapa pun (atau server apa pun) dapat mereplika ulang environment kita secara persis.
Buat requirements.txt
| |
pip freeze mencantumkan semua paket yang dipasang dengan versi spesifik. > menjadikan output itu ke dalam file. Hasilnya akan terlihat kira-kira seperti:
asgiref==3.8.1
Django==5.1.4
djangorestframework==3.15.2
sqlparse==0.5.3
Cara menggunakan file requirements.txt (di mesin lain atau environment baru)
| |
Update requirements.txt
Setiap kali kita memasang paket baru, buat ulang file:
| |
Cara nonaktifkan environment jika setelah selesai
| |
Mengapa Virtual Environment Penting untuk Kode Production
Berikut adalah alasan mengapa isolasi penting, bukan sekedar good habit:
| Concern | Potensi masalah jika tidak menggunakan Virtual Environment |
|---|---|
| Dependency Conflicts | Dua project membutuhkan versi berbeda dari library yang sama - salah satu rusak |
| Reproducibility | Orang lain clone repo kita tetapi mendapatkan versi package berbeda, menyebabkan adanya potensi bug |
| Deployment | Server production kita menggunakan versi package yang lebih baru yang tidak sesuai dengan kita butuhkan |
| Pipeline CI/CD | Automated test runners membutuhkan environment yang clean dan sudah terbukti berjalan dengan baik |
Kombinasi requirements.txt dan virtual environment adalah cara kita untuk memberikan informasi: “This exact set of packages, at these exact versions, is what makes this project work.”
Cheat Sheet
| |
Kebiasaan Baik Yang Perlu Dimulai Sejak Dini
Tambahkan .venv/ ke .gitignore segera. Kita seharusnya tidak pernah melakukan commit folder virtual environment ke Git, karena ukurannya besar, platform-specific, dan sudah diwakilkan oleh file requirements.txt.
| |
