En av de største trekkene til Python er det ekspansive økosystemet med tredjepartspakker. Hvis det er en oppgave du vil utføre - filformatkonvertering, skraping og restrukturering av nettsider, lineær regresjon, kan du si det - oddsen er at en eller flere pakker i Python Package Index vil fylle dine behov.
Den vanskelige delen er å administrere akkumulering av pakker i en gitt Python-installasjon. Det er altfor lett å tankeløst installere dusinvis av pakker og med tiden ende opp med et Python-miljø fylt med konflikter mellom eldre og nyere versjoner av verktøy, noe som gjør arbeidet vanskeligere enn det trenger å være.
Python kommer med et automatisert system for å holde et pakkesett lokalt til et gitt Python-prosjekt. Virtuelle miljøer - med tillatelse fra virtualenv verktøy i Python 2 og venv i Python 3 — kan brukes til å lage en separat, isolert forekomst av Python-kjøretiden for et prosjekt, med sitt eget komplement av pakker.
I denne artikkelen vil vi gå gjennom noen av de vanlige feilene folk gjør - og har ord de gir etter for - når vi jobber med virtuelle miljøer i Python.
Bruk Python virtuelle miljøer
Den første vanlige feilen Python-programmerere gjør med virtualenv ellervenv er å bare ikke bry seg med det. Hvis alt du gjør er å kaste sammen et raskt og skittent manus å gjøre en liten ting, hvorfor bry seg med å sette opp et virtuelt miljø i det hele tatt?
Problemet er at "en liten ting" ofte viser seg å være mye, mye mer. Når du mestrer Python, vil du uunngåelig ende opp med å trekke i flere tredjepartsmoduler for å oppnå mer sofistikert arbeid. Dessuten vil du finne det stadig vanskeligere å håndtere avhengigheter av tidligere versjoner av pakker, et av de viktigste problemene virtuelle miljøer ble opprettet for å løse.
Noen mennesker rynker også på nesa ved bruk virtualenv ellervenv fordi hvert virtuelle miljø er sin egen lille kopi av Python-kjøretiden, og tar omtrent 25 MB. Men diskplass er latterlig billig i disse dager, og å fjerne et virtuelt miljø er like salig som å slette katalogen (ingen bivirkninger). I tillegg, hvis du har flere oppgaver som deler et felles sett med pakker, kan du alltid bruke det samme virtuelle miljøet for dem begge.
Bruk virtualenvwrapper til å administrere Python virtuelle miljøer
En måte å gjøre virtuelle miljøer mindre belastende er å brukevirtualenvwrapper. Dette verktøyet lar deg administrere alle de virtuelle miljøene i arbeidsområdet ditt fra en enkelt, sentral kommandolinjeapp.
Et råd om skapelse av virtuelt miljø: Ikke navngi katalogen til det virtuelle miljøet dittvenv—Eller for den saks skyld navnet på en hvilken som helst annen pakke du vil bruke i det virtuelle miljøet. Dette kan ha uforutsigbare effekter på import senere. Bruk et navn som beskriver prosjektet entydig.
Ikke plasser prosjektfiler i et virtuelt Python-miljø
Når du konfigurerer et virtuelt miljø, er ikke katalogen det bor i ment å inneholde annet enn det virtuelle miljøet. Prosjektet ditt hører hjemme i sitt eget separate katalogtrær. Det er mange gode grunner til dette:
- Prosjektkatalogtreet ditt kan godt ha en navnekonvensjon som kolliderer med elementer i det virtuelle miljøet.
- Den enkle måten å fjerne et virtuelt miljø på er å slette katalogen. Blanding av prosjektfiler med det virtuelle miljøet betyr at du først må løsne de to.
- Flere prosjekter kan bruke samme virtuelle miljø.
En måte å organisere ting på ville være å lage en toppkatalog som inneholder forskjellige virtuelle miljøer, og en annen toppkatalog som inneholder prosjekter. Så lenge de to holdes adskilte, er det det som betyr noe.
Ikke glem å aktivere ditt virtuelle Python-miljø
En annen vanlig feil folk gjør med virtuelle miljøer, er å glemme å aktivere dem, eller ikke aktivere den rette.
Før et virtuelt miljø kan brukes i en bestemt shell-økt, må det være det aktivert, ved hjelp av et skript som heter aktivere i det virtuelle miljøet Skript katalog. Ved aktivering blir det virtuelle miljøet behandlet som standard Python-forekomst til du deaktiverer det (ved å kjøre deaktivere kommando).
Det er lett å glemme dette trinnet først, både fordi det er en vane som må anskaffes, og fordi aktiveringsskriptet er ett nivå nede i katalogen for virtuelt miljø. Et par triks kommer godt med her:
- Lag snarveier til aktiverings- / deaktiveringsskriptene i rotkatalogen til prosjektet ditt. Du kan nevne snarveiene noe enkelt som
handlingogdeaktiverfor å gjøre dem mindre motbydelige å skrive. - For prosjekter som du jobber med fra en IDE og ikke en kommandolinje, oppretter du en prosjektstarter - en batchfil eller skallskript - for den aktuelle Python-appen. Dette lar deg ringe aktiveringsskriptet, og deretter kjøre ditt eget skript etterpå. Du trenger generelt sett ikke å deaktivere skriptmiljøet etter løpet, fordi økten avsluttes av seg selv uansett.
Dette siste trikset understreker et viktig poeng om aktivering av virtuelle omgivelser: De gjelder bare miljøøkten de kjører i. Hvis du for eksempel starter to kommandolinjesessioner og aktiverer et virtuelt miljø i en, vil den andre kommandolinjesesjonen bruke systemets standard Python-installasjon, ikke det virtuelle miljøet. Du aktiverer ikke det virtuelle miljøet for systemet som en helhet, men bare for den spesifikke økten.
Ikke bruk>= for pakkeversjon som festes i et virtuelt Python-miljø
Dette tipset er også nyttig utenfor virtuelle miljøer. Når du har en app med en krav.txt fil, bør du spesifisere pakker med en nøyaktig versjonsnummer. Si min pakke == 2.2, ikke min pakke> = 2.2.
Her er hvorfor. En av hovedårsakene til å bruke et virtuelt miljø er å sikre bruk av spesifikke versjoner av pakker. Hvis du bruker >= i stedet for ==, det er ingen garanti for at du - eller noen andre - vil ende opp med samme versjon hvis miljøet må gjenskapes for det prosjektet. Bruk et nøyaktig versjonsnummer. Du, en fremtid du og den som kommer etter deg, vil takke deg.
