Pythoni venv ja eraldatud keskkonnad

Selles peatükis selgitame, miks venv vajalik on ja kuidas seda kasutada.

Loogika

venv ei ole Pythoni juures lihtsalt järjekordne rituaal, vaid väga praktiline viis hoida projektid üksteisest lahus.

Põhiküsimus ei ole "kuidas teha .venv", vaid:

miks mitte paigaldada kõike lihtsalt süsteemi
miks üks projekt töötab ja teine enam mitte
miks IDE, terminal ja pip peavad nägema sama Pythoni keskkonda

See on seotud paketihalduse ja IDE peatükkidega, sest:

pip paigaldab paketid
venv määrab, kuhu need paigaldatakse
IDE peab kasutama sama keskkonda

Miks `venv` vajalik on

Pythoni paketid võivad eri projektides vajada erinevaid versioone. Virtuaalkeskkond hoiab projektisõltuvused eraldi.

Kõige tavalisemad päris probleemid ilma venv-ta on:

projekt A tahab requests ühte versiooni, projekt B teist
pip install ... paigaldab paketi "kuhugi", aga hiljem ei saa aru, millise Pythoniga see seotud on
IDE kasutab üht interpreterit, terminal teist
süsteemi Python või muud tööriistad saavad kogemata sinu katsetustest mõjutatud

Lühidalt:

venv aitab vältida segadust
venv teeb projektid korratavamaks
venv teeb veaotsingu lihtsamaks

Mis `venv` tegelikult teeb

venv loob projektikausta sisse eraldi Pythoni keskkonna, kus on:

oma python
oma pip
oma installitud paketid

Tüüpiline kaust on:


.venv/

Oluline mõte on:

süsteemi Python jääb alles oma kohale
projekt kasutab omaenda koopiat või viidet Pythoni keskkonnale
kui oled selle keskkonna aktiveerinud, siis käsud python ja pip viitavad just sellele projektile

See on põhjus, miks prompti ette ilmub sageli:


(.venv)

See ei ole iluasi. See on kasulik hoiatus, et praegu töötad projekti lokaalses keskkonnas.

Ilma `venv`-ta vs koos `venv`-ga

Ilma venv-ta võib töövoog olla selline:


pip install requests
python app.py

Probleem on selles, et hiljem ei pruugi olla selge:

millise pip-iga sa paigaldasid
millise python-iga sa jooksutad
kas paigaldasid süsteemi, kasutaja või mõne muu keskkonna alla

Koos venv-ga on loogika palju selgem:


python3 -m venv .venv
source .venv/bin/activate
python -m pip install requests
python app.py

Siis kehtib rusikareegel:

kõik selle projekti Pythoni paketid lähevad .venv sisse
kui projekt ei tööta, otsid viga sellest keskkonnast
kui projekt enam ei vaja seda keskkonda, võid .venv isegi kustutada ja uuesti luua

Miks see on algajale kasulik

venv on kasulik mitte ainult suures meeskonnas, vaid just algajale, sest:

ta teeb "kus mu paketid on?" küsimuse palju lihtsamaks
ta vähendab hirmu, et rikud süsteemi Pythoni ära
ta õpetab kohe projekti tasemel mõtlema

Hea algaja mõtteviis on:

üks projekt, üks .venv
projekti terminal, IDE ja pip peavad viitama samale keskkonnale

Kas neid `venv`-sid peab olema palju

Tavaliselt mitte. Hea rusikareegel on:

üks projekt, üks .venv
kui sul on kaks eri projekti, siis neil võiks olla eri venv-d
sama projekti iga väikese katse jaoks ei pea uut venv-i looma

See tähendab praktiliselt:

kui töötad ühe repo sees, piisab enamasti ühest .venv-st
kui teed täiesti teist projekti teise sõltuvuste komplektiga, tee uus .venv
kui kaks projekti vajavad eri versioone samast paketist, peavad neil olema eri venv-d

Halb harjumus on:

üks suur globaalne pip install ... kõigi projektide jaoks

Hea harjumus on:

iga Pythoni projekt hoiab oma sõltuvused iseenda juures

Millal `venv` ei ole nii oluline

Kõigi ühe-realiste katsetuste jaoks ei pea alati venv-i looma.

Näiteks:

python3 -c 'print("tere")'
väga lühike ühekordne skript
puhas õppimine ilma lisapakettideta

Aga niipea kui:

projektis on välised sõltuvused
tahad kasutada IDE-d
tahad projekti hiljem uuesti käivitada
jagad projekti teistega

siis on venv juba väga mõistlik harjumus.

Kiirspikker

python3 -m venv .venv loob keskkonna
source .venv/bin/activate aktiveerib selle
python -m pip install ... paigaldab paketi
python -m pip list näitab selle keskkonna pakette
deactivate väljub keskkonnast

Kõige tavalisemad käsud

python3 -m venv .venv loo projektile keskkond
source .venv/bin/activate aktiveeri see shellis
python -m pip install requests paigalda pakett sellesse keskkonda
python -m pip list vaata, mis on paigaldatud
deactivate välju keskkonnast

Käivita need käsud


mkdir -p ~/tmp/python-naide
cd ~/tmp/python-naide
python3 -m venv .venv
source .venv/bin/activate
python -m pip install requests
python -m pip list
deactivate

Mida siin ekraanil näha võiks

Sageli muutub prompt näiteks selliseks:


(.venv) vilo@macbook python-naide %

See tähendab, et:

oled endiselt samas kataloogis
aga python ja pip tulevad nüüd .venv keskkonnast

Kontrolli seda soovi korral nii:


command -v python
command -v pip

Tõenäoline tulemus on, et teed osutavad nüüd kausta .venv/bin/.

Hea praktiline töövoog

Kui alustad uut Pythoni projekti, siis üsna hea vaikimisi rütm on:


mkdir uus-projekt
cd uus-projekt
python3 -m venv .venv
source .venv/bin/activate
python -m pip install -U pip
python -m pip install requests

Seejärel:

vali IDE-s interpreteerijaks .venv/bin/python
hoia projektifailid samas kaustas
ära paigalda projekti sõltuvusi niisama süsteemi

Üks aus tähelepanek

venv ei lahenda kõiki sõltuvuste probleeme automaatselt.

Ta ei tee näiteks sinu eest:

versioonide lukustamist
requirements.txt või pyproject.toml haldust
pakettide konfliktide mõistmist

Aga ta teeb ühe väga suure asja ära: ta piirab segaduse ühe projekti sisse.

`venv` vs Docker

Need kaks ei ole päris samad tööriistad.

venv isoleerib:

Pythoni paketid

Docker isoleerib:

terve käivituskeskkonna
operatsioonisüsteemi kasutajaruumi
süsteemipaketid ja sõltuvused
vajadusel ka teenused ja võrgukeskkonna

Hea lühike reegel on:

kui probleem on ainult Pythoni pakettides, vali venv
kui vajad tervet ühtlast keskkonda, vali Docker

Millal piisab `venv`-st

venv on sageli täiesti piisav siis, kui:

teed puhast Pythoni projekti
vajad ainult pip-i kaudu paigaldatavaid teeke
töötad üksi või väikeses tiimis
tahad kiiresti arendada ilma konteinerikihti juurde toomata

Näited:

väike CLI-tööriist
andmetöötluse skript
lihtne veebirakendus arenduse alguses
testide jooksutamine lokaalses Pythoni projektis

Millal minna Dockerisse

Docker muutub mõistlikuks siis, kui:

tahad, et kõigil oleks sama keskkond
vajad lisaks Pythonile süsteemipakette nagu libpq, ffmpeg, imagemagick
projekt käib koos andmebaasi, Redis-e, Nginx-i või muu teenusega
tahad sama keskkonda arenduses, CI-s ja serveris

Näited:

veebirakendus koos Postgres-iga
teenus, mis sõltub kindlast Linuxi paketist
meeskonnaprojekt, kus "minu masinas töötab" on sage probleem

Kas kasutada `venv`-i Dockeri sees

Enamasti:

lokaalses arenduses võib sul olla venv
Dockeri konteineri sees ei ole eraldi venv sageli vajalik

Põhjus on lihtne:

konteiner ise juba isoleerib keskkonna
ühe rakenduse konteineris ei ole tavaliselt vaja Pythoni pakette veel teise kihi sisse peita

Tavaline praktiline muster on:

kohalikus masinas arendad venv-ga
tootmises või ühtses arenduskeskkonnas jooksutad Dockerit

venv konteineri sees võib siiski mõnikord olla mõistlik, kui:

konteineris on mitu eri Pythoni töövoogu
tahad väga teadlikult hoida eraldi tööriistu ja rakendust
sul on eriline buildi- või testivajadus

Aga alguses tasub mõelda nii:

väljaspool konteinerit: venv
konteineri sees: enamasti piisab konteinerist endast

Minitest

Loo uus virtuaalkeskkond.
Aktiveeri see.
Paigalda üks lihtne pakett ja kuva installitud paketid.
Kontrolli, kuhu käsud python ja pip aktiveerimise järel osutavad.
Selgita ühe lausega, miks venv on kasulik isegi siis, kui sul on ainult üks väike projekt.