Vieningos Python aplinkos: nuo venv ir Conda iki uv

Pagrindinis » Pitonas » Vieningos Python aplinkos: nuo venv ir Conda iki uv

Darbas su Python realiuose projektuose greitai atskleidžia skaudžią tiesą: vienos pasaulinės Python instaliacijos nepakanka. Vos tik pradedate naudoti daugiau nei vieną programą, susiduriate su priklausomybių konfliktais, versijų neatitikimais ir klasikine „mano kompiuteryje viskas veikia“ problema. Vienai programai reikia „Django 2.2“, kitai – „Django 4.2“, duomenų srautas laikosi „pandas 1.3“, o nešiojamasis kompiuteris tikisi „pandas 2.0“ – visko diegimas visoje sistemoje tiesiog kelia problemų.

Vieninga ir izoliuota Python aplinka yra išeitis iš šios netvarkos. Derindami virtualias aplinkas, šiuolaikiniai priklausomybių valdytojai, pvz. pieputis, Conda, Poezija, Pipenv, pdm ir didelio našumo įrankiai, tokie kaip uv, galite kiekvienam projektui suteikti atskirą „Python“ versiją ir paketų rinkinį, išlaikyti savo OS „Python“ nepažeistą ir patikimai atkurti nustatymus skirtinguose kompiuteriuose, CI/CD kanaluose ir gamybos serveriuose.

Kodėl suvienodintos Python aplinkos yra tokios svarbios

Visų aplinkos įrankių pagrindas yra poreikis izoliuoti priklausomybes tarp projektų. Bendrai naudojamame, visoje sistemoje įdiegtame „Python“ pakete gali būti tik viena kiekvienos bibliotekos versija, tačiau tikruose projektuose retai kada sutariama dėl vienos versijos. Jei A programa paketą prisega prie 1.0 versijos, o B programai reikalinga 3.0 versija, vienos programos diegimas visame pasaulyje neišvengiamai sugadins kitą.

Virtualios aplinkos tai išsprendžia sukurdamos atskirus diegimo katalogus, kurių kiekvienas turi savo „Python“ interpretatorių ir svetainių paketus. Įsivaizduokite kiekvieną aplinką kaip atskirą mini „Python“ visatą: vienas projektas gali paleisti „Flask 1.1“, kitas – „Flask 2.0“, nelipdami vienas kitam ant kojų. Bibliotekos atnaujinimas vienoje aplinkoje nepaveikia visų kitų projektų.

Šis izoliavimas yra labai svarbus komandos aplinkoje ir gamybinėje aplinkoje. Be jo kūrėjas, diegdamas „nedidelį“ atnaujinimą, gali staiga sugadinti senąją paslaugą arba CI užduotis gali būti sėkminga, o gamybinė aplinka gali nepavykti dėl skirtingų bibliotekų versijų. Aplinkos, užrakinimo failai ir atkuriami diegimai pašalina šį atsitiktinumą.

Suvienodinti darbo eigos siekia visa tai sujungti į vieną nuoseklią įrankių grandinę. Užuot rankiniu būdu maišę „pip“, „venv“, „virtualenv“, „pyenv“, „Conda“, „requirements.txt“ ir atsitiktinius apvalkalo scenarijus, šiuolaikiniai įrankiai, tokie kaip „uv“, stengiasi pasiūlyti vieną darnią sąsają aplinkų kūrimui, priklausomybių sprendimui, versijų užrakinimui, komandų vykdymui ir net paketų kūrimui bei publikavimui.

Klasikinės Python virtualios aplinkos: venv ir virtualenv

Įdiegtas Python atsakymas į izoliuotas aplinkas yra venv modulis, pristatytas „Python 3.3“. Jis pateikiamas su „Python 3“, todėl jums nereikia nieko papildomai diegti. venv aplinka yra tiesiog katalogas, kuriame yra Python interpretatorius, standartinė biblioteka, pip ir aktyvinimo scenarijus.

Norėdami sukurti pagrindinę virtualią aplinką, paprastai paleidžiate tokią komandą: python -m venv .venv iš savo projekto aplanko. Tai sukuria .venv/ katalogą su viskuo, ko reikia norint atskirai paleisti programą. Naudojant pavadinimą .venv laiko jį paslėptą daugelyje failų naršyklių ir terminalų ir išvengia konfliktų su .env failai, naudojami aplinkos kintamiesiems.

Sukūrus aplinką, ją aktyvuojate taip, kad jūsų apvalkalas naudotų tą Python, o ne sisteminį. „Windows“ sistemoje paleidžiate kažką panašaus .venv\Scripts\activate; „Unix“ arba „macOS“ sistemose, kurias paprastai naudojate source .venv/bin/activateKitiems kriauklėms, tokioms kaip Csh or žuvisalternatyvūs aktyvinimo scenarijai, pvz. activate.csh bei activate.fish yra numatyta.

Po aktyvinimo jūsų raginime paprastai rodomas aplinkos pavadinimas ir python bei pip komandos automatiškai susiejamos su ta aplinka. Galite diegti bibliotekas, vykdyti scenarijus ir derinti kodą neliesdami globalių paketų. Kai baigsite, paprastas deactivate grąžina jus į „Python“ sistemą.

prieš venv egzistavo, kūrėjai plačiai naudojo trečiųjų šalių įrankius virtualenv, ir jis vis dar labai populiarus. virtualenv veikia senesnėse „Python“ versijose (įskaitant „Python 2“) ir siūlo papildomas parinktis, pvz., pasirinkti konkretų interpretatorių su --python=/path/to/python, kuriant greitesnes aplinkas optimizuojant arba kontroliuojant, ar matomi visuotiniai svetainių paketai.

Konceptualus požiūris: aplinkos kaip izoliuotos virtuvės jūsų kodui

Naudingas mentalinis modelis – įsivaizduoti save kaip virėją, gaminantį kelis firminius patiekalus. Užuot nuolat keisdami vieną pagrindinį receptą, kiekvienam eksperimentui saugote atskiras kopijas. Kiekvienoje kopijoje galima naudoti savo ingredientus, metodus ir laiką, nerizikuojant originaliu patiekalu. Python virtualios aplinkos veikia būtent taip: kiekvienas projektas gauna savo receptą ir savo ingredientų sandėliuką.

Praktiškai „Python“ virtuali aplinka yra savarankiškas katalogų medis. Jame yra konkretus Python interpretatorius, jo standartinė biblioteka, vietinis site-packages katalogą ir aktyvinimo scenarijų rinkinį. Aktyvavus, importuojami ir įdiegiami paketai patenka tik į tą medį, o ne į jūsų visuotinius sistemos failus.

Kai keli projektai naudoja skirtingas tos pačios bibliotekos versijas, ši izoliacija apsaugo juos nuo susidūrimų. Galite turėti vieną aplinką „Vonage + Flask“ projektui, kurioje naudojama „Flask 1.1.2“, ir kitą aplinką, kurioje veikia „Vonage“ su „Flask 2.0.1“. Abi gali būti tame pačiame kompiuteryje, tačiau jų reikalavimai yra tvarkomi ir diegiami atskirai.

Virtualios aplinkos taip pat yra pagrindas, padedantis išvengti galvos skausmo „bet mano kompiuteryje veikia“. Kai jūsų priklausomybės bus tvarkingai užfiksuotos ir užfiksuotos, komandos nariai ir CI serveriai galės atkurti tiksliai tokią pačią aplinką, taip smarkiai sumažindami netikėtų klaidų, atsirandančių dėl subtilių versijų skirtumų, skaičių.

Žingsnis po žingsnio kuriant ir valdant virtualias aplinkas

Pagrindinis virtualios aplinkos gyvavimo ciklas visada yra tas pats: sukurti, aktyvuoti, įdiegti paketus, naudoti ir, kai baigsite, deaktyvuoti. Nesvarbu, ar jūs naudojate venv, virtualenv arba „Conda“, modelis iš tikrųjų nesikeičia – keičiasi tik komandos.

Su virtualenv, pagrindinis darbo eigos procesas atrodo maždaug taip: pirmiausia įdiekite jį su pip install virtualenv, tada patikrinkite su virtualenv --versionNorėdami sukurti aplinką, naudokite virtualenv my-env arba įtraukti --python=/usr/bin/python3.12 nukreipti į konkretų vertėją. Tai sukuria my-env/ aplanką, kuriame yra jūsų Python dvejetainiai failai ir bibliotekų katalogai.

Sukūrus aplinką, ją aktyvuojate, kad galėtumėte ja naudotis. Unix tipo sistemose source my-env/bin/activate atlieka triuką; sistemoje „Windows“ naudojate scenarijus, esančius skiltyje my-env\Scripts\Jūsų apvalkalo eilutėje bus rodomas aplinkos pavadinimas, kad galėtumėte matyti, kuri iš jų šiuo metu aktyvi, ir viską. pip Įdiegimai bus apriboti tik šia aplinka.

Priklausomybių diegimas tampa paprastas, kai aplinka yra aktyvi. Galite bėgti pip install some-package arba taškas pip ne requirements.txt failą su pip install -r requirements.txtJei norite užfiksuoti dabartinį įdiegtų paketų rinkinį, paleiskite pip freeze > requirements.txt kad kiti galėtų atkurti tą pačią konfigūraciją.

Kai baigsite dirbti su ta aplinka, bėkite. deactivate grįžti prie to Python, kurį anksčiau naudojo jūsų apvalkalas. Jei aplinkos jums tikrai nebereikia, galite tiesiog ištrinti jos katalogą; aplanke nėra nieko magiško, tai tik failai diske.

Efektyvus pip naudojimas virtualiose aplinkose

Standartinė „Python“ paketų tvarkyklė, pip, yra pagrindinė sąsaja, skirta bibliotekoms diegti, atnaujinti ir šalinti aplinkoje. Kai jūsų aplinka aktyvi, kiekvienas pip komanda manipuliuoja tik ta aplinka, o ne jūsų sistemos „Python“.

Įprastos subkomandos apima install, uninstall, show, list bei freeze. Naujausios paketo versijos įdiegimas yra toks pat paprastas, kaip pip install package-nameJei jums reikia tikslios versijos, galite naudoti == operatorius, pavyzdžiui pip install requests==2.31.0Pakartotinai paleidus diegimą, bus nustatyta, kad versija jau yra, ir pakartotinis diegimas bus praleistas, nebent pakeisite versiją arba pridėsite --upgrade.

Norėdami peržiūrėti, kas šiuo metu įdiegta, pip list suteikia jums apžvalgą ir pip show package-name spausdina informaciją apie konkretų paketą. Kai diegimui reikalinga kompiuterio skaitoma momentinė kopija, pip freeze išveda visus paketus ir tikslias versijas, į kurias paprastai rašote requirements.txtTas failas gali būti saugomas versijų valdymo sistemoje kartu su jūsų kodu.

Diegimas iš requirements.txt yra tai, kaip atkuriate aplinką kažkur kitur. Bendradarbis, CI užduotis arba serveris pirmiausia sukurtų ir suaktyvintų virtualią aplinką, o tada paleistų pip install -r requirements.txtKadangi failas nurodo versijas, kiekviename kompiuteryje gaunate beveik identiškas aplinkas, jei pagrindinė OS ir „Python“ versijos yra suderinamos.

O pip yra neįtikėtinai lankstus, jis yra sąmoningai žemo lygio, todėl ant jo atsirado aukštesnio lygio įrankiai. Įrankiai kaip pip-tools, Poetry, Pipenv bei uv remtis priklausomybių prisegimo idėja, bet automatizuoti sprendimų priėmimą, užrakinimą, aplinkos valdymą ir kita.

„Conda“ aplinkos moksliniams ir duomenų gausos darbo krūviams

Duomenų mokslui, mašininiam mokymuisi ir skaitmeniniam kodui daugelis komandų teikia pirmenybę Conda kaip jų aplinka ir paketų tvarkyklė. „Conda“ yra nepriklausoma nuo kalbos ir gali įdiegti tiek patį „Python“, tiek sisteminio lygio bibliotekas, tokias kaip BLAS, LAPACK arba CUDA, todėl ji idealiai tinka sudėtingiems stekams, kuriuose derinami kompiliuojami ir interpretuojami komponentai.

Norėdami pradėti naudoti „Conda“, įdiekite „Anaconda“ arba „Miniconda“. „Anaconda“ pateikiama su dideliu iš anksto įdiegtų paketų rinkiniu, o „Miniconda“ yra mažesnė diegimo programa, kurioje yra tik „Conda“, „Python“ ir keli pagrindiniai komponentai, leidžiantys pridėti viską kita, kai reikia. Dauguma kūrėjų naudoja „Miniconda“, kad viskas būtų paprasta.

„Conda“ aplinka kuriama naudojant conda create --name my-env, pasirinktinai pridedant python=3.11 arba specialius paketus, pvz. numpy or pandas toje pačioje komandinėje eilutėje. „Conda“ išspręs priklausomybes, atsisiųs tinkamas jūsų platformai versijas ir įdės jas į izoliuotą aplinkos katalogą, kurį tvarko pati „Conda“.

Aktyvavimą ir deaktyvavimą atlieka conda activate my-env bei conda deactivate. Kai aktyvūs, diegiami paketai su conda install naudoja „Conda“ saugyklas, kurios dažnai pateikia optimizuotus dvejetainius failus. Daugelyje darbo eigų derinate „Conda“ sudėtingoms mokslinėms bibliotekoms ir pip bendresnėms, tik „Python“ skirtoms priklausomybėms, pirmiausia įdiekite „Conda“ paketus, o po to įdiekite „pip“ paketus, kad sumažintumėte konfliktų.

„Conda“ taip pat puikiai veikia, kai reikia eksportuoti ir klonuoti visas aplinkas. Su conda env export > environment.yml fiksuojate ne tik „Python“ paketus, bet ir metaduomenis, pvz., platformą ir kanalus. Kitame kompiuteryje conda env create -f environment.yml sukuria identišką aplinką, kuri puikiai tinka tyrimų atkuriamumui ir bendradarbiavimo projektams.

Šiuolaikiniai projektų vadovai: PIP + VENV vs. PIPENV, Poetry, PDM ir UV

Laikui bėgant, „Python“ ekosistema išsivystė iš „pip + virtualenv + requirements.txt“ į labiau pagrįstas priemones, kurios suvienodina priklausomybių valdymą, aplinkas ir pakavimą. Nors klasikinis trejetas vis dar puikiai veikia, daugelis komandų dabar renkasi integruotus darbo eigą.

Tradiciniai nustatymai remiasi pip bei virtualenv or venv, su rankų darbo requirements.txt failas. Jūs rankiniu būdu sukuriate virtualią aplinką, ją aktyvuojate, diegiate priklausomybes ir prižiūrite savo užšaldymo bei atnaujinimo logiką. Šis metodas yra itin lankstus, tačiau jį taip pat lengva sukonfigūruoti neteisingai, jei komandos nėra drausmingos.

Pipenv sukūrė aukštesnio lygio sąsają, derindama priklausomybių valdymą su automatiniu virtualenv kūrimu. Jis naudoja Pipfile bei Pipfile.lock aprašyti ir prisegti savo priklausomybes. Istoriškai „Pipenv“ priklausomybių sprendimas ir našumas kartais būdavo lėti, todėl žmonės buvo priversti svarstyti alternatyvas.

Poetry eina dar toliau, siūlydama visavertį projektų vadovą, kuris tvarko priklausomybes, kompiliavimą ir publikavimą vienoje priemonėje. Jis remiasi šiuolaikiniais pyproject.toml standartą (PEP 621) ir rašo poetry.lock failas TOML formatu. „Poetry“ paprastai patikimai sprendžia priklausomybes, elegantiškai palaiko versijų apribojimus ir leidžia lengvai publikuoti „PyPI“ naudojant tokias komandas kaip poetry publish.

pdm yra dar vienas šiuolaikinis vadovas, kuris taip pat naudoja pyproject.toml ir daugiausia dėmesio skiria greitam ir PEP reikalavimus atitinkančiam darbo eigai. Tai palaiko tiek virtualias aplinkas, tiek alternatyvius metodus, tokius kaip PEP 582 (vietinis __pypackages__ katalogus) ir siūlo pažangias skiriamosios gebos bei projektų valdymo funkcijas, panašias į „Poetry“, pirmenybę teikdamas greičiui ir lankstumui.

Pastaruoju metu uv pasirodė kaip našus, suvienodintas įrankis, siekiantis būti panašus į „Cargo for Python“. Jis pozicionuoja save kaip vieną dvejetainį failą, parašytą „Rust“ kalba, apimantį kelias galimybes: priklausomybių sprendimą, aplinkos valdymą, „Python“ versijos diegimą, scenarijų vykdymą, užrakinimą, kūrimą ir publikavimą.

Kuo UV išsiskiria vieningose ​​Python aplinkose?

uv yra sukurtas tam, kad pakeistų daugelį atskirų įrankių, siūlant itin greitą, integruotą darbo eigą. Projekto lyginamieji testai rodo, kad jis yra maždaug 8–10 kartų greitesnis nei „pip“ ir „pip-tools“ be talpyklos, o naudojant talpyklą – iki maždaug 80–115 kartų greitesnis, todėl aplinkų sinchronizavimas ar atkūrimas yra beveik momentinis.

Iš esmės „uv“ teikia projekto API, kuri tvarko priklausomybių valdymą, aplinkos kūrimą, užrakinimo failus ir įrankių vykdymą. Komandos patinka uv init sukurti naują projektą su pagrindine struktūra: a pyproject.toml, .python-version failas ir starteris main.pyTai suteikia nuoseklų išdėstymą beveik be rankinio nustatymo.

Kai paleisite uv add some-package, uv automatiškai sukuria .venv aplinka (jei reikia), atnaujinimai pyproject.toml ir rašo uv.lock failas. Užrakinimo failas įrašo tikslias išspręstas kiekvienos priklausomybės versijas ir maišos vertes, užtikrindamas atkartojamą diegimą. Skirtingai nuo daugelio kitų įrankių, uv.lock yra aiškiai daugiaplatformis, todėl tą patį failą galima naudoti „Linux“, „Windows“ ir „macOS“, vis tiek užtikrinant deterministinius rezultatus.

Kita galinga savybė yra uv run, kuris vykdo komandas projekto aplinkoje nereikalaujant, kad pirmiausia jį rankiniu būdu aktyvuotumėte. Prieš vykdydamas, uv įsitikina, kad aplinka atitinka dabartinę pyproject.toml bei uv.lock, kad netyčia nepaleistumėte kodo, nukreipto prieš pasenusias priklausomybes. Tai sumažina dažnų uv sync or uv lock skambučiai.

Vienkartiniam komandinės eilutės įrankių naudojimui UV apšviečia uvx bei uv tool run. Šios komandos leidžia paleisti CLI, pvz. black, pytest or pyinstaller nepridedant jų visam laikui kaip projekto priklausomybių. Jie ypač praverčia CI kanaluose arba scenarijuose, kur įrankio reikia tik trumpam.

Išsamiai aptarkime UV PIP režimą ir konfigūraciją

Vienas iš „UV“ projektavimo tikslų – būti paprastu daugelio „pip“ darbo eigų atnaujinimu. Įprastoms operacijoms galite tiesiogine prasme keistis pip install forumas uv pip install ar naudojimas uv pip sync kad būtų galima atspindėti reikalavimų failą. Daugelyje esamų projektų tai supaprastina diegimą ir sumažina riziką.

Nepaisant to, „uv“ sąmoningai nėra tobulas „pip“ klonas, o keli skirtumai yra sąmoningi patobulinimai. Pavyzdžiui, „uv“ neskaito „pip“ konfigūracijos failų, tokių kaip pip.conf or PIP_INDEX_URLVietoj to, jis naudoja savo aplinkos kintamuosius, pvz. UV_INDEX_URL ir saugo konfigūraciją uv.toml arba [tool.uv.pip] dalis pyproject.tomlTai sumažina atsitiktinį susiejimą su besivystančia pip semantika.

Indekso prioritetizavimas yra dar viena sritis, kurioje UV pagal numatytuosius nustatymus sustiprina saugumą. Siekiant apsisaugoti nuo priklausomybių painiavos atakų, uv teikia pirmenybę vidiniams paketų indeksams, o ne PyPI, kai abu pagal numatytuosius nustatymus pateikia paketą su tuo pačiu pavadinimu. Yra vėliavėlė --index-strategy koreguoti šį elgesį, tačiau saugus numatytasis nustatymas padeda išvengti subtilių tiekimo grandinės problemų įmonėse.

Skirtingai nuo „pip“, „uv“ yra sukurtas remiantis virtualiomis aplinkomis kaip numatytuoju diegimo tikslu. Komandos patinka uv pip install bei uv pip sync bus įdiegta į šiuo metu aktyvią aplinką arba automatiškai aptiks .venv kataloge dabartiniame arba pagrindiniame aplanke. Tai leidžia atsisakyti visuotinių diegimų ir pereiti prie atskirų projektų diegimo iš karto.

Pagal numatytuosius nustatymus, uv praleidžia kompiliavimą .py į .pyc baitinį kodą diegimo metu, kuris padeda išlaikyti didelį greitį. Python vis tiek kompiliuosis importavimo metu, jei reikės. Jei jums svarbus paleidimo laikas CLI įrankiuose ar konteineriuose, galite įjungti greitą kompiliavimą su --compile-bytecode iš anksto sugeneruoti baitinį kodą diegimo metu.

Užrakinimo failai, eksportavimas ir kelių šaltinių priklausomybės su uv

Geriausios uv.lock failas yra pagrindinis UV atkuriamumo istorijos elementas. Tai TOML dokumentas, kuriame yra visi išspręsti paketai, tikslios versijos, šaltinio registrai, maišos, atsisiuntimo URL, dydžiai ir įkėlimo laiko žymos. Priešingai nei pyproject.toml, kuris išreiškia versijų diapazonus ir ketinimą (pavyzdžiui, requests >= 2.30), užrakinimo faile aprašomas tikslus artefaktų rinkinys, kuris turėtų būti įdiegtas.

UV rekomenduoja įrašyti užrakinimo failą į versijų valdymo sistemą. Tokiu būdu bet koks vykdomas kūrėjo ar CI darbas uv sync or uv pip install pagal „lockfile“ gauna lygiai tokį patį priklausomybių rinkinį visose palaikomose operacinėse sistemose. Tai žymiai padidina pasitikėjimą diegiant naujas versijas.

Jei reikia sąveikumo su tradiciniais įrankiais, „uv“ gali eksportuoti kitus formatus iš savo užrakinimo failo. Naudojant tokias komandas kaip uv export --format requirements.txt or uv export --format pylock.toml, galite sukurti klasikinį requirements.txt failai arba standartizuotas pylock.toml kuriuos supranta ir kiti įrankiai. Tai leidžia daug sklandžiau perkelti laipsnišką migraciją iš senesnių srautų.

Dar viena pažangi UV funkcija yra lankstus kelių indeksų ir šaltinių tvarkymas. In pyproject.toml galite apibrėžti kelis [[tool.uv.index]] įrašus, pavyzdžiui, „PyPI“ veidrodį, „PyTorch“ rato indeksą GPU kompiliacijoms arba vidinį paketų registrą, o tada susieti konkrečias priklausomybes su šiais šaltiniais pagal [tool.uv.sources].

Tai reiškia, kad galite, pavyzdžiui, atsiimti torch iš pasirinktinio CUDA rato indekso, kita priklausomybė tiesiai iš „Git“ saugyklos, trečia iš tiesioginio rato URL ir dar viena iš vietinio kelio redaguojamu režimu – visa tai tame pačiame projekto faile. Tai galingas būdas centralizuoti sudėtingus priklausomybių grafikus be išsklaidytos konfigūracijos.

Įrankių kūrimas, publikavimas ir paleidimas naudojant UV

Be priklausomybių valdymo, UV taip pat tvarko Python paketų kūrimą ir publikavimą. Norėdami naudoti uv kaip kūrimo posistemį, jūsų pyproject.toml reikia a [build-system] skyrių nuorodos uv_build, pavyzdžiui: requires = ["uv_build >= 0.7.13, < 0.8"] bei build-backend = "uv_build"Tai galite nustatyti projekto inicijavimo metu naudodami uv init --build-backend uv.

Sukonfigūravus, paleidus uv build sukuria a dist/ katalogą su jūsų šaltinio ir „wheel“ distribucijomis. Šie artefaktai yra paruošti įkėlimui į jūsų pasirinktą indeksą arba vidinį registrą. UV automatiškai jų nepublikuoja; kūrimas ir publikavimas yra atskiri veiksmai, siekiant išlaikyti aiškų valdymą.

Norėdami publikuoti, pridėkite indekso konfigūraciją dalyje [[tool.uv.index]] su publish-url, dažnai nurodantis į PyPI įkėlimo galinį tašką. Pavyzdžiui, galite apibrėžti indeksą pavadinimu pypi su url = "https://pypi.org/simple/" bei publish-url = "https://upload.pypi.org/legacy/", tada uv publish įkels jūsų sukurtus paskirstymus ten, panašiai kaip naudojant twine bet integruota į tą patį įrankį.

UV taip pat supaprastina darbą su CLI įrankiais per uvx bei uv tool run. Užuot įdiegę tokias komunalines paslaugas kaip pytest, black or pyinstaller visam laikui jūsų aplinkoje, galite juos iškviesti pagal poreikį. Tai ypač naudinga CI užduotims arba trumpalaikėms užduotims, kai norite, kad projekto priklausomybės būtų kuo mažesnės, tačiau vis tiek turite prieigą prie turtingos įrankių ekosistemos.

Kaip konkretų pavyzdį, jei pakuojate „Python“ programą į „Windows“ .exe naudojant pyinstaller, UV suteikia jums keletą galimybių. Galite pridėti „pyinstaller“ kaip projekto priklausomybę su uv add pyinstaller ir tada paleiskite jį per uv run pyinstaller ..., kuris užtikrina, kad jis būtų užrakintas pagal versiją ir būtų jūsų aplinkos dalis. Arba, jei norite greitai atlikti vienkartinį pakavimo darbą, galite naudoti uvx pyinstaller ... paleisti jį be oficialaus diegimo. Abu metodai veikia su kelių failų projektais; „pyinstaller“ seks importavimą ir sujungs modulius, išteklius ir net atsisiųstus modelius, tokius kaip „Whisper“, jei į juos teisingai bus nuorodos jūsų kode ar specifikacijų faile.

Aplinkų integravimas su IDE, užrašų knygelėmis ir darbo eigomis

Tvirta aplinka yra tik pusė darbo – jūsų redaktorius ir įrankiai turi jas naudoti. Populiarios IDE, tokios kaip „VS Code“ ir „PyCharm“, turi aukščiausios klasės palaikymą virtualių aplinkų aptikimui ir darbui su jomis, o „Jupyter“ gali jas užregistruoti kaip atskirus branduolius.

„VS Code“ paprastai leidžiate „Python“ plėtiniui automatiškai aptikti .venv aplankai jūsų projekto medyje. Tada komandų paletėje per „Python: Select Interpreter“ pasirenkate tinkamą interpretatorių. Pasirinkus jį, „VS Code“ naudoja tą aplinką integruotam terminalui, derinimo įrankiui ir kalbos funkcijoms ir automatiškai ją suaktyvina atidarius naujus terminalus.

„PyCharm“ siūlo panašiai sklandžią integraciją, susiedamas konkretų interpretatorių arba virtualenv su kiekvienu projektu. Nustatymų dialogo lange galite pridėti naują „Virtualenv“ aplinką arba nurodyti esamą. Po to „PyCharm“ ją netiesiogiai suaktyvina visoms vykdymo konfigūracijoms ir integruotame terminale, todėl retai kada reikia galvoti apie rankinį aktyvavimą.

„Jupyter“ nešiojamųjų kompiuterių atveju svarbiausias žingsnis yra diegimas ipykernel į savo aplinką ir užregistruokite jį kaip branduolį. Paleidus kažką panašaus python -m ipykernel install --user --name myenv, jūsų aplinka „Jupyter“ branduolio sąraše bus rodoma kaip „myenv“. Tai leidžia lengvai sinchronizuoti užrašines su atitinkama projekto aplinka, išvengiant nedidelių neatitikimų.

Taip pat yra nešiojamiesiems kompiuteriams skirtų įrankių, kurie pašalina didelę dalį šių funkcijų. Sprendimai, integruojantys dirbtinio intelekto asistentus arba aplinkos automatizavimą, pavyzdžiui, specializuotus „Jupyter“ vartotojo sąsajos elementus, gali automatiškai nustatyti ir palaikyti virtualias aplinkas fone, kad duomenų mokslininkai galėtų daugiau dėmesio skirti eksperimentams, o mažiau – aplinkos nustatymui.

Dažniausios klaidos ir geriausia praktika kuriant vieningas aplinkas

Net ir naudojant brandžius įrankius, kūrėjai susiduria su pasikartojančiomis problemomis valdydami aplinkas. Tipinės problemos apima netinkamo „Python“ interpretatoriaus naudojimą, trūkstamus aktyvinimo scenarijus, vykdymo politikos klaidas „Windows PowerShell“ sistemoje arba atsitiktinius diegimus globalioje „Python“ aplinkoje, o ne numatytoje.

Jei jūsų aplinkoje atsiranda netinkama Python versija, ją reikia aiškiai atkurti naudojant tinkamą interpretatorių. Pavyzdžiui, python3.11 -m venv .venv or virtualenv --python=/usr/bin/python3.11 .venv užtikrina, kad į aplinką būtų integruota tinkama vykdymo aplinka. Sistemose, kurios naudoja pyenv, pirmiausia galite pasirinkti vietinę „Python“ versiją ir tada sukurti savo aplinką.

Kai atrodo, kad aktyvinimo scenarijai trūksta arba yra sugadinti, tai dažnai reiškia, kad aplinka nebuvo tinkamai sukurta. Ištrinant aplanką ir sukuriant jį iš naujo naudojant atitinkamą python -m venv or virtualenv komanda paprastai išsprendžia problemą. Sistemoje „Windows“, jei „PowerShell“ blokuoja aktyvinimą, gali tekti sušvelninti dabartinio vartotojo vykdymo politiką.

Kad netyčia neįdiegtumėte paketų netinkamoje „Python“ programoje, visada patikrinkite, kurie python bei pip jūs naudojate. Komandos patinka which python or where python (sistemoje „Windows“) ir python -m site galite patvirtinti, ar esate numatytoje aplinkoje. Jei keliai nurodo į sistemos vietas, o ne į jūsų .venv aplanką, atsargiai išjunkite ir vėl įjunkite.

Gera pavadinimų ir versijų valdymo higiena labai padeda užtikrinti lengvai prižiūrimas aplinkas. Naudokite aiškius, nuoseklius aplinkų pavadinimus, rinkitės vieną aplinką vienam projektui ir niekada neįtraukite paties aplinkos katalogo. Vietoj to pridėkite tokius įrašus kaip .venv/ or venv/ jūsų .gitignore ir pasikliauti užrakinimo failais bei reikalavimų failais, kad prireikus būtų galima atkurti aplinkas.

Galiausiai, trumpame README skyriuje aprašyta, kaip kurti ir atnaujinti aplinkas, ateityje jums ir komandos draugams nereikės spėlioti. Paprastas dviejų eilučių fragmentas, pavyzdžiui, python -m venv .venv po pip install -r requirements.txt or uv sync – gali gerokai sklandžiau įdiegti ir išlaikyti vieningą „Python“ aplinkos strategiją nuoseklią visoje komandoje.

Derindami klasikinius įrankius, tokius kaip „venv“, „virtualenv“, „pip“ ir „Conda“, su moderniais tvarkytuvais, tokiais kaip „Poetry“, „pdm“ ir „uv“, galite sukurti vieningą aplinkos darbo eigą, kuri yra greita, atkuriama ir saugi. Kiekvienas projektas gauna savo izoliuotą visatą, užrakinimo failai garantuoja nuoseklų diegimą, IDE ir nešiojamieji kompiuteriai sklandžiai prisijungia, o didelio našumo įrankiai, tokie kaip UV, viską sujungia po vienu stogu, paversdami tai, kas anksčiau buvo netvarkinga scenarijų kolekcija, nuosekliu, patikimu pagrindu rimtam Python kūrimui.