En af de største træk ved Python er dets ekspansive økosystem af tredjepartspakker. Hvis der er en opgave, du vil udføre - konvertering af filformat, skrabning og omstrukturering af websider, lineær regression, skal du navngive det - odds er, at en eller flere pakker i Python Package Index vil udfylde dit behov.
Den hårde del er at styre akkumuleringen af pakker i en given Python-installation. Det er alt for let at tankeløst installere snesevis af pakker og med tiden ende med et Python-miljø fyldt med konflikter mellem ældre og nyere versioner af værktøjer, hvilket gør arbejdet hårdere, end det skal være.
Python leveres med et automatiseret system til at holde et pakkesæt lokalt til et givet Python-projekt. Virtuelle miljøer - takket være virtualenv værktøj i Python 2 og venv i Python 3 — kan bruges til at oprette en separat, isoleret forekomst af Python-runtime til et projekt med sit eget supplement til pakker.
I denne artikel vil vi gennemgå nogle af de almindelige fejl, som folk laver - og fik dem, de bøjer under - når vi arbejder med virtuelle miljøer i Python.
Brug Python virtuelle miljøer
Den første almindelige fejl, som Python-programmører laver med virtualenv ellervenv er at bare ikke gider med det. Hvis alt hvad du laver, er at kaste et hurtigt og snavset script sammen en lille ting, hvorfor gider man oprette et virtuelt miljø overhovedet?
Problemet er, at "en lille ting" ofte viser sig at være meget, meget mere. Når din beherskelse af Python vokser, vil du uundgåeligt ende med at trække i flere tredjepartsmoduler for at udføre mere sofistikeret arbejde. Hvad mere er, vil du finde det stadig sværere at håndtere afhængigheder af tidligere versioner af pakker, et af de vigtigste problemer, virtuelle miljøer blev oprettet for at løse.
Nogle mennesker rynker også på næsen ved brug virtualenv ellervenv fordi hvert virtuelle miljø er sin egen lille kopi af Python-runtime, der tager cirka 25 MB. Men diskplads er latterligt billigt i disse dage, og at fjerne et virtuelt miljø er lige så simpelt som at slette dets bibliotek (ingen bivirkninger). Plus, hvis du har flere opgaver, der deler et fælles sæt pakker, kan du altid bruge det samme virtuelle miljø til dem begge.
Brug virtualenvwrapper til at styre virtuelle Python-miljøer
En måde at gøre virtuelle miljøer mindre belastende er at brugevirtualenvwrapper. Dette værktøj giver dig mulighed for at administrere alle de virtuelle miljøer i dit arbejdsområde fra en enkelt, central kommandolinjeapp.
Et råd om oprettelse af virtuelt miljø: Undlad at navngive mappen til dit virtuelle miljøvenv—Eller for den sags skyld navnet på enhver anden pakke, du vil bruge i det virtuelle miljø. Dette kan have uforudsigelige virkninger på importen senere. Brug et navn, der beskriver dit projekt utvetydigt.
Placer ikke projektfiler i et virtuelt Python-miljø
Når du opretter et virtuelt miljø, er det bibliotek, det lever i, ikke beregnet til at rumme andet end det virtuelle miljø. Dit projekt hører hjemme i sit eget separate katalogtræ. Der er mange gode grunde til dette:
- Dit projektkatalogtræ kan meget vel have en navngivningskonvention, der kolliderer med elementer i det virtuelle miljø.
- Den nemme måde at fjerne et virtuelt miljø på er at slette biblioteket. Blanding af projektfiler med det virtuelle miljø betyder, at du først skal adskille de to.
- Flere projekter bruger muligvis det samme virtuelle miljø.
En måde at organisere ting på ville være at oprette en top-top mappe, der indeholder forskellige virtuelle miljøer, og en anden top-level mappe, der indeholder projekter. Så længe de to holdes adskilt, er det det der betyder noget.
Glem ikke at aktivere dit virtuelle Python-miljø
En anden almindelig fejl, som folk begår med virtuelle miljøer, er at glemme at aktivere dem eller ikke aktivere den rigtige.
Før et virtuelt miljø kan bruges i en bestemt shell-session, skal det være aktiveret, ved hjælp af et script navngivet aktivere i det virtuelle miljø Scripts vejviser. Efter aktivering behandles det virtuelle miljø som standard Python-instansen, indtil du deaktiverer det (ved at køre deaktiver kommando).
Det er let at glemme dette trin i starten, både fordi det er en vane, der skal erhverves, og fordi aktiveringsscriptet er et niveau nede i det virtuelle miljøkatalog. Et par tricks er nyttige her:
- Opret genveje til aktiverings- / deaktiveringsskripterne i rodmappen på dit projekt. Du kan navngive disse genveje noget simpelt som
handlingogdeaktiverfor at gøre dem mindre modbydelige at skrive. - For projekter, som du arbejder på fra en IDE og ikke en kommandolinje, skal du oprette en projektstarter - en batchfil eller shell-script - til den pågældende Python-app. Dette giver dig mulighed for at ringe til aktiveringsscriptet og derefter køre dit eget script bagefter. Du behøver generelt ikke at deaktivere scriptmiljøet efter kørslen, fordi sessionen alligevel afsluttes alene.
Dette sidste trick understreger et vigtigt punkt om aktivering af virtuelle omgivelser: De gælder kun for den miljøsession, de kører i. Hvis du f.eks. Starter to kommandolinjesessioner og aktiverer et virtuelt miljø i en, vil den anden kommandolinjesession bruge systemets standard Python-installation, ikke det virtuelle miljø. Du aktiverer ikke det virtuelle miljø for systemet som en helhed, men kun til den specifikke session.
Brug ikke>= til fastgørelse af pakkeversion i et virtuelt Python-miljø
Dette tip er også nyttigt uden for virtuelle miljøer. Når du har en app med en krav.txt fil, skal du angive pakker med en eksakt version nummer. Sige min pakke == 2.2, ikke min pakke> = 2.2.
Her er hvorfor. En af hovedårsagerne til at bruge et virtuelt miljø er at sikre brugen af specifikke versioner af pakker. Hvis du bruger >= i stedet for ==, der er ingen garanti for, at du - eller en anden - ender med den samme version, hvis miljøet skal genskabes til dette projekt. Brug et nøjagtigt versionsnummer. Du, en fremtid, dig og den, der kommer efter dig, vil takke dig.
