Kodėl virtualios aplinkos – ne prabanga, o būtinybė
Prisimenu savo pirmąsias dienas su Python. Įsidiegiau biblioteką čia, atnaujinau paketą ten, ir viskas atrodė puikiai – kol nebuvo. Vienas projektas reikalavo Django 2.2, kitas – jau 4.0 versiją. Viena aplikacija veikė su NumPy 1.19, o kita kategoriškai atsisakė startuoti su bet kuo, kas ne 1.21. Ir štai tuomet supratau, kad mano sistema virto chaotiška bibliotekų sąvartynu, kur vienas projektas gali sugadinti kitą vien tuo, kad įdiegiau naują paketą.
Virtualios aplinkos – tai Python ekosistemos atsakas į šią problemą. Jos leidžia kiekvienam projektui turėti savo izoliuotą erdvę su savo priklausomybėmis, versijomis ir nustatymais. Tarsi kiekvienas projektas gyventų savo bute, o ne viename bendrabutyje su visais kitais.
Kaip virtualios aplinkos iš tikrųjų veikia
Virtualios aplinkos principas gana paprastas, nors iš pirmo žvilgsnio gali atrodyti kaip kažkas sudėtingo. Kai sukuriate virtualią aplinką, Python tiesiog sukuria atskirą katalogų struktūrą jūsų projekte. Ten atsiranda kopija Python interpretatoriaus (arba nuoroda į jį), tuščias site-packages katalogas bibliotekoms ir keli pagalbiniai skriptai.
Kai „aktyvuojate” virtualią aplinką, iš esmės tiesiog pakeičiate sistemos PATH kintamąjį taip, kad komandos python ir pip nukreiptų ne į sisteminį Python, o į tą, kuris yra jūsų virtualios aplinkos kataloge. Viskas, ką įdiegsite su pip, atsiduris šiame izoliuotame kataloge, neliesdamas sisteminių bibliotekų.
Štai kodėl galite turėti dešimt projektų su dešimčia skirtingų Django versijų – kiekvienas projektas žiūri tik į savo virtualios aplinkos bibliotekas ir nė nenutuokia apie kitus.
venv – įmontuotas sprendimas, kuris tiesiog veikia
Nuo Python 3.3 versijos į standartinę biblioteką įtrauktas venv modulis. Tai reiškia, kad jums nereikia nieko papildomai diegti – jei turite Python, turite ir virtualių aplinkų kūrimo įrankį.
Sukurti naują virtualią aplinką neįtikėtinai paprasta:
python -m venv mano_projektas_env
Ši komanda sukurs katalogą mano_projektas_env su visa reikiama struktūra. Dažniausiai šį katalogą pavadinu tiesiog venv arba .venv (su tašku pradžioje, kad būtų paslėptas Unix sistemose).
Aktyvavimas priklauso nuo jūsų operacinės sistemos. Linux ir macOS:
source venv/bin/activate
Windows su Command Prompt:
venv\Scripts\activate.bat
O Windows su PowerShell:
venv\Scripts\Activate.ps1
Kai aplinka aktyvuota, jūsų terminalo eilutės pradžioje pamatysite aplinkos pavadinimą skliausteliuose, pavyzdžiui (venv). Tai vizualus patvirtinimas, kad dirbate izoliuotoje erdvėje.
Deaktyvuoti aplinką dar paprasčiau – visose sistemose tiesiog:
deactivate
Praktiniai darbo su venv patarimai
Per metus intensyvaus darbo su Python projektais išmokau kelių dalykų, kurie gerokai palengvina gyvenimą. Pirma, visada įtraukite virtualios aplinkos katalogą į .gitignore. Nėra jokios prasmės versijuoti tūkstančius failų, kuriuos bet kas gali atkurti viena komanda. Jūsų .gitignore failas turėtų turėti:
venv/
.venv/
env/
ENV/
Antra, naudokite requirements.txt failą. Tai standartas Python bendruomenėje, leidžiantis užfiksuoti visas projekto priklausomybes. Kai turite aktyvuotą virtualią aplinką su visomis reikiamomis bibliotekomis, eksportuokite jas:
pip freeze > requirements.txt
Dabar bet kas (įskaitant jus patį po šešių mėnesių) gali atkurti tiksliai tokią pačią aplinką:
pip install -r requirements.txt
Trečia, jei dirbate su keliais Python versijomis, galite nurodyti konkrečią versiją kuriant aplinką:
python3.9 -m venv venv
Tai ypač naudinga, kai testuojate suderinamumą su skirtingomis Python versijomis arba kai jūsų projektas dar nepalaiko naujausios versijos.
virtualenv ir virtualenvwrapper – kai reikia daugiau galimybių
Nors venv puikiai tinka daugumai situacijų, yra ir alternatyvų su papildomomis funkcijomis. virtualenv – tai trečiųjų šalių įrankis, kuris egzistavo dar prieš venv atsiradimą standartinėje bibliotekoje. Jis vis dar populiarus, nes:
– Greitesnis aplinkų kūrimas
– Palaiko senesnes Python versijas (iki 2.7)
– Turi daugiau konfigūracijos galimybių
Įdiegti jį galima per pip:
pip install virtualenv
Naudojimas beveik identiškas:
virtualenv mano_aplinka
Bet kur virtualenv tikrai spindi, tai kartu su virtualenvwrapper (Linux/macOS) arba virtualenvwrapper-win (Windows). Šis įrankis prideda komandų rinkinį, kuris daro virtualių aplinkų valdymą daug patogesniu.
Po įdiegimo ir konfigūracijos galite:
mkvirtualenv projektas1 – sukurti ir iš karto aktyvuoti naują aplinką
workon projektas1 – perjungti į bet kurią aplinką iš bet kurios vietos
lsvirtualenv – pamatyti visas turimas aplinkas
rmvirtualenv projektas1 – ištrinti aplinką
Visos aplinkos saugomos vienoje vietoje (paprastai ~/.virtualenvs/), todėl nereikia prisiminti, kuriame projekto kataloge yra venv aplankas. Aš asmeniškai naudoju virtualenvwrapper ir negaliu įsivaizduoti, kaip be jo dirbau anksčiau.
pipenv – priklausomybių valdymas nauju lygiu
pipenv bando sujungti virtualių aplinkų valdymą su moderniu priklausomybių valdymu, panašiu į tai, ką turi Node.js su npm arba Ruby su Bundler. Vietoj requirements.txt, jis naudoja Pipfile ir Pipfile.lock.
Įdiegimas:
pip install pipenv
Naudojimas intuityvus:
pipenv install requests – sukuria virtualią aplinką (jei jos dar nėra) ir įdiegia paketą
pipenv shell – aktyvuoja aplinką
pipenv install --dev pytest – įdiegia development priklausomybes
Pipfile atrodo švariau ir skaitomiau nei requirements.txt, o Pipfile.lock užtikrina, kad visi komandos nariai naudoja tiksliai tas pačias versijas, įskaitant subpriklausomybes.
Tačiau pipenv turi ir trūkumų. Jis gali būti lėtas didelių projektų atveju, kartais atsiranda keistų konfliktų sprendžiant priklausomybes, ir ne visi CI/CD įrankiai jį palaiko taip gerai kaip tradicinį requirements.txt. Aš jį naudoju mažesniuose projektuose, bet dideliems komerciiniams projektams vis dar linkęs prie venv + requirements.txt kombinacijos.
Poetry – šiuolaikiškas Python projektų valdymas
Jei pipenv atrodė ambicingas, poetry eina dar toliau. Tai visapusiškas Python projektų valdymo įrankis, apimantis ne tik virtualias aplinkas ir priklausomybes, bet ir pakuočių kūrimą, publikavimą į PyPI, ir daug daugiau.
Įdiegimas šiek tiek skiriasi (rekomenduojama naudoti oficialų installer):
curl -sSL https://install.python-poetry.org | python3 -
Poetry naudoja pyproject.toml failą – naują standartą Python projektuose, apibrėžtą PEP 518. Pradėti naują projektą:
poetry new mano_projektas
Arba inicijuoti esamame kataloge:
poetry init
Diegti priklausomybes:
poetry add requests
Paleisti komandas virtualios aplinkos kontekste:
poetry run python script.py
Arba aktyvuoti shell:
poetry shell
Kas man labiausiai patinka Poetry – tai kaip jis sprendžia priklausomybių konfliktus. Jis turi pažangų resolver’į, kuris dažnai randa sprendimus ten, kur pip tiesiog meta klaidą. Be to, poetry.lock failas užtikrina absoliučiai identiškas aplinkas visur.
Tačiau Poetry turi mokymosi kreivę ir prideda papildomą abstrakcijos sluoksnį. Jei tik pradėjote su Python, geriau pradėti nuo venv, o prie Poetry grįžti, kai suprasite pagrindus.
Conda – kai Python yra tik dalis galvosūkio
Jei dirbate su duomenų mokslu, mašininiu mokymusi ar moksliniais skaičiavimais, tikriausiai susidūrėte su Conda. Tai ne tik virtualių aplinkų valdymo įrankis – tai visas pakuočių ir aplinkų valdymo ekosistema, kuri gali tvarkyti ne tik Python bibliotekas, bet ir C bibliotekas, R paketus, ir kitus priklausomybes.
Conda ypač naudinga, kai reikia įdiegti paketus su sudėtingomis kompiliuotomis priklausomybėmis. Pavyzdžiui, įdiegti TensorFlow ar PyTorch su pip gali būti skausmingas procesas Windows sistemoje, o su Conda tai paprastai veikia iš karto.
Sukurti Conda aplinką:
conda create -n mano_aplinka python=3.9
Aktyvuoti:
conda activate mano_aplinka
Įdiegti paketus:
conda install numpy pandas matplotlib
Conda gali naudoti ir pip paketus, jei ko nors nėra Conda repozitorijose:
conda install pip
pip install kažkas-egzotiško
Pagrindinis Conda trūkumas – ji sunki. Miniconda instaliacijos failas yra apie 50 MB, o pilna Anaconda distribucija – kelių gigabaitų. Be to, Conda aplinkos užima daug daugiau vietos nei venv aplinkos. Tačiau jei dirbate su duomenų mokslu, šie trūkumai paprastai nustelbiami privalumais.
Kaip išsirinkti ir neklysti
Po visų šių įrankių apžvalgos, tikriausiai klausiate: kurį gi rinktis? Atsakymas, kaip dažnai būna IT, yra „priklauso”.
Jei esate naujokas arba kuriate paprastą web aplikaciją, pradėkite nuo venv. Jis įmontuotas, paprastas, ir veikia visur. Jokių papildomų priklausomybių, jokios magijos – tik paprasta, patikima izoliacija.
Jei dirbate su keliais projektais ir norite patogesnio valdymo, išbandykite virtualenvwrapper. Tai nedidelis patogumų sluoksnis virš virtualenv, kuris gerokai palengvina kasdienį darbą.
Jei kuriate biblioteką ar norite modernaus priklausomybių valdymo, žiūrėkite į Poetry. Jis tampa de facto standartu naujiems Python projektams ir turi puikią dokumentaciją.
Jei dirbate su duomenų mokslu, mašininiu mokymusi ar turite sudėtingų ne-Python priklausomybių, Conda yra jūsų draugas. Taip, ji sunki, bet ji išsprendžia problemas, kurias kiti įrankiai net nebando spręsti.
O pipenv? Jis vis dar gyvas ir turi savo nišą, bet aš asmeniškai rekomenduočiau rinktis arba tradicinį venv + pip, arba šokti tiesiai į Poetry. Pipenv yra tarsi tarpinė stotelė, kuri nebeturi aiškios vietos ekosistemoje.
Svarbiausia – naudokite bent ką nors. Dirbti be virtualių aplinkų 2024 metais yra kaip programuoti be versijų kontrolės. Techniškai įmanoma, bet kodėl gi sau taip daryti? Pirmą kartą, kai sutaupysite valandas neieškodami, kodėl projektas staiga nustojo veikti po sisteminės bibliotekos atnaujinimo, suprasite, kad virtualios aplinkos – tai ne papildomas sudėtingumas, o laisvė nuo sudėtingumo.
