Virtual Environment

Setiap proyek deep learning memiliki kebutuhan versi paket yang berbeda: satu proyek dapat membutuhkan NumPy 2.1 bersama PyTorch 2.14, sementara proyek lain terikat pada kombinasi versi yang lebih lama. Apabila semua paket dipasang ke satu Python yang sama, pip dipaksa menyesuaikan versi paket bersama setiap kali ada proyek baru dijalankan. Virtual environment (venv) menyelesaikan masalah tersebut dengan memberi setiap proyek folder paket dan salinan interpreter miliknya sendiri. Chapter ini membawa kita praktik dari awal: membuat venv, mengaktifkannya, memasang paket, memverifikasi bahwa isolasi benar-benar bekerja, lalu membekukan daftar paket agar mudah dibagikan.

Masalah Berbagi Paket Antar Proyek #

Secara bawaan, pip memasang paket ke satu lokasi site-packages milik interpreter yang dipakai. Seluruh skrip yang berjalan dengan interpreter tersebut melihat versi paket yang sama. Konsekuensinya, memperbarui paket untuk satu proyek secara diam-diam mengubah perilaku proyek lain di komputer yang sama. Perbandingan berikut merangkum perbedaan bekerja dengan dan tanpa venv:

venv bukan mesin virtual atau container. venv hanyalah struktur folder berisi tautan ke interpreter Python, salinan pip, dan folder site-packages yang terpisah, sehingga pembuatannya cepat dan ukurannya kecil.

Alur Kerja Proyek yang Terisolasi #

Sebelum masuk ke perintah konkret, mari kita lihat posisi venv di dalam siklus hidup proyek. Diagram berikut menunjukkan alur lengkap dari pembuatan proyek sampai berpindah ke proyek lain:

Inti pola pada diagram di atas: venv dibuat sekali per proyek, diaktifkan setiap kali kita mulai bekerja, lalu dinonaktifkan saat berpindah. Folder venv tidak perlu dibagikan karena isinya dapat dibangun ulang dari daftar paket.

Membuat Virtual Environment #

Pastikan paket python3-venv sudah terpasang pada Debian/Ubuntu (lihat Chapter Instalasi Python). Untuk demo ini kita membuat venv sekali pakai di /tmp dengan nama demo-venv; pada proyek nyata, ganti lokasinya ke dalam folder proyek dengan nama .venv:

python3 -m venv /tmp/demo-venv

Perintah tersebut tidak mencetak apa pun saat berhasil. Kita bisa memastikan hasilnya dengan melihat isi foldernya:

ls /tmp/demo-venv

Output yang Dihasilkan:

bin
include
lib
lib64
pyvenv.cfg

Tiga item terpenting dari struktur tersebut:

• bin — berisi python3, pip, dan skrip aktivasi; inilah interpreter yang akan dipakai proyek.
• lib — berisi site-packages, lokasi seluruh paket yang dipasang ke venv.
• pyvenv.cfg — berkas konfigurasi kecil yang mencatat versi Python dan lokasi interpreter dasar.

Mengaktifkan Virtual Environment #

Aktivasi mengubah lingkungan shell agar perintah python3 dan pip menunjuk ke salinan di dalam venv. Perintahnya berbeda antar sistem operasi:

Kita jalankan aktivasi untuk venv demo di Linux, lalu memeriksa variabel VIRTUAL_ENV yang diatur oleh skrip aktivasi:

source /tmp/demo-venv/bin/activate
echo $VIRTUAL_ENV

Output yang Dihasilkan:

/tmp/demo-venv

Setelah aktivasi, prompt shell akan ditambahi nama venv, misalnya (demo-venv) $. Untuk keluar dari venv, jalankan perintah deactivate — shell kembali memakai Python semula.

Memasang Paket ke Dalam Virtual Environment #

Dengan venv aktif, pip install kini menulis ke site-packages milik venv, bukan milik interpreter utama. Kita uji dengan memasang NumPy:

pip install numpy

pip mencetak progres pengunduhan selama proses berlangsung; baris akhir yang menandakan keberhasilan tampak seperti berikut:

Successfully installed numpy-2.5.4

Sekarang kita pastikan NumPy terpasang dengan benar di dalam venv:

python3 -c "import numpy as np; print('numpy', np.__version__)"

Output yang Dihasilkan:

numpy 2.5.4

Interpreter yang menjalankan import numpy adalah /tmp/demo-venv/bin/python3, sehingga versi yang tampil berasal dari paket yang baru saja dipasang ke venv demo.

Memastikan Isolasi dengan sys.prefix #

Cara paling meyakinkan untuk membuktikan kita berada di dalam venv adalah membandingkan dua atribut interpreter. Skrip berikut kita simpan sebagai berkas agar dapat dipakai ulang di proyek apa pun:

import sys

print("sys.prefix      :", sys.prefix)
print("sys.base_prefix :", sys.base_prefix)

if sys.prefix != sys.base_prefix:
    print("Status          : di dalam virtual environment")
else:
    print("Status          : di interpreter utama")

Output yang Dihasilkan (dijalankan dengan venv /tmp/demo-venv aktif):

sys.prefix      : /tmp/demo-venv
sys.base_prefix : /home/z/.local/share/uv/python/cpython-3.12.15-linux-x86_64-gnu
Status          : di dalam virtual environment

Mari kita telaah kode di atas baris per baris:

1. Baris 1 (import sys): mengimpor modul sys yang menyimpan identitas interpreter yang sedang berjalan.
2. Baris 3 (sys.prefix): lokasi site-packages aktif. Di dalam venv, nilainya menunjuk ke folder venv (/tmp/demo-venv).
3. Baris 4 (sys.base_prefix): lokasi interpreter dasar yang menjadi asal venv. Di luar venv, sys.prefix dan sys.base_prefix bernilai sama.
4. Baris 6-9 (if sys.prefix != ...): membandingkan kedua nilai tersebut; perbedaan keduanya adalah tanda bahwa interpreter berjalan dari dalam sebuah venv.

Membekukan Daftar Paket #

Terakhir, kita catat seluruh paket terpasang beserta versinya ke dalam bentuk yang siap dibagikan:

pip freeze

Output yang Dihasilkan:

numpy==2.5.4

Format nama==versi itulah isi berkas requirements.txt. Rekan kerja yang menerima berkas tersebut dapat membangun ulang lingkungan yang identik dengan pip install -r requirements.txt — mekanisme lengkapnya kita bahas pada Chapter Manajemen Dependensi.

Ringkasan #

Pada Chapter ini kita membuat venv di /tmp/demo-venv, mengaktifkannya, memasang NumPy tanpa menyentuh interpreter utama, membuktikan isolasi lewat sys.prefix, dan membekukan daftar paket dengan pip freeze. Dengan pola ini, setiap proyek deep learning memiliki ruang paketnya sendiri dan bebas dari konflik versi. Venv yang baru dibuat masih kosong; pada Chapter berikutnya kita mengisinya dengan Jupyter Notebook, antarmuka interaktif yang menjadi tempat utama kita bereksperimen dengan kode deep learning.