Sådan administreres flere Python-versioner og virtuelle miljøer

Tilføjelse januar 2019: Hvis du kommer tilbage til denne blog efter opgradering til macOS Mojave, bedes du se dette github-spørgsmål for en løsning på det fælles pyenv 'zlib ikke tilgængelig' problem.

Før vi begynder, lad os kort gennemgå de udtryk, der bruges i titlen:

  • Flere Python-versioner : Forskellige installationer af Python på den samme maskine, f.eks. 2.7 og 3.4.
  • Virtuelle miljøer : isolerede uafhængige miljøer, der kan have både en specifik version af Python og af eventuelle projektspecifikke pakker installeret i dem uden at påvirke andre projekter.

Her ser vi på tre forskellige værktøjer til at arbejde med disse, og hvornår du muligvis har brug for hver enkelt. Lad os undersøge brugssagerne til:

  • venv / pyvenv
  • pyenv
  • pyenv-virtualenv

Hvis du bruger en enkelt udgave af Python sige versionen 3.3+ , og ønsker at administrere forskellige virtuelle miljøer,venver alt hvad du behøver.

Hvis du vil bruge flere versioner af Python ved 3.3+ , med eller uden virtuelle miljøer , skal du fortsætte med at læse om pyenv.

Hvis du også vil arbejde med Python 2 , pyenv-virtualenver det et værktøj at overveje.

venv

Fra Python 3.3+ er venvpakken inkluderet. Det er ideelt til at skabe lette virtuelle miljøer.

Indtil Python 3.6 blev et kaldet script pyvenvogså inkluderet som en indpakning venv, men dette er udfaset. Det fjernes fuldstændigt i Python 3.8. Den nøjagtige samme funktionalitet er tilgængelig, når du bruger venv, og enhver eksisterende dokumentation skal opdateres. For alle interesserede kan du læse årsagerne til afskrivninger pyvenv.

venv bruges til at skabe et nyt miljø via terminalkommandoen:

$ python3 -m venv directory-name-to-create

aktiveret med:

$ source name-given/bin/activate

og deaktiveret med blot:

$ deactivate

Hvis du har brug for at fjerne miljøet fuldstændigt efter deaktivering, kan du køre:

$ rm -r name-given

Som standard er det miljø, det skaber, den aktuelle version af Python, du bruger. Hvis du skriver dokumentation og ønsker den ekstra sikkerhed for, at den korrekte version af Python bruges af din læser, kan du angive hoved- og mindre versionsnummer i kommandoen, sådan:

$ python3.6 -m venv example-three-six

Hvis læseren bruger en anden version end 3.6, vil kommandoen ikke blive vellykket og vil angive i sin fejlmeddelelse. Enhver patchversion (f.eks. 3.6.4) fungerer dog.

Når miljøet er aktivt, kan alle pakker installeres på det pipsom normalt. Som standard inkluderer det nyoprettede miljø ikke pakker, der allerede er installeret på maskinen. Da det i pipsig selv ikke nødvendigvis vil blive installeret på maskinen. Det anbefales at først opgradere piptil den nyeste version ved hjælp af pip install --upgrade pip.

Projekter har ofte en requirements.txtfil, der angiver dens afhængighed. Dette gør det muligt for pip install -r requirements.txtkommandokommandoen til genvej hurtigt at installere alle pakker i det nyoprettede virtuelle miljø. De vil kun eksistere i det virtuelle miljø. Det vil ikke være tilgængeligt, når det er deaktiveret, men vil fortsætte, når det genaktiveres.

Hvis du ikke har brug for yderligere versioner af selve Python, er dette alt hvad du behøver for at oprette isolerede, projektspecifikke, virtuelle miljøer.

pyenv

Hvis du ønsker at bruge flere versioner af Python på en enkelt maskine, pyenver det et almindeligt anvendt værktøj til at installere og skifte mellem versioner. Dette må ikke forveksles med det tidligere nævnte afskrevne pyvenvscript. Den leveres ikke sammen med Python og skal installeres separat.

Den pyenvdokumentation indeholder en stor beskrivelse af, hvordan det virker, så her vil vi se blot på hvordan man bruger det.

For det første skal vi installere det. Hvis du bruger Mac OS X, kan vi gøre dette ved hjælp af Homebrew, ellers overvej andre installationsmuligheder.

$ brew update $ brew install pyenv

Dernæst tilføj følgende mod bunden af ​​dine shell-scripts for at tillade pyenvautomatisk at ændre versioner for dig:

eval "$(pyenv init -)"

For at gøre, skal du åbne din i brug shell script, via $ ~/.zshrc, $ ~/.bashrceller $ ~/.bash_profileog kopiere og indsætte ovenstående linje i.

Kørsel pyenv versionsviser, hvilke Python-versioner der i øjeblikket er installeret med en *ved siden af ​​den, der i øjeblikket er i brug. pyenv versionviser dette direkte og python --versionkan bruges til at bekræfte dette.

Hvis du vil installere en ekstra version, 3.4.0skal du bare sige det pyenv install 3.4.0.

pyenv ser fire steder for at beslutte, hvilken version af Python der skal bruges, i prioriteret rækkefølge:

  1. Det PYENV_VERSIONmiljø variabel (hvis angivet). Du kan bruge pyenv shellkommandoen til at indstille denne miljøvariabel i din nuværende shell-session.
  2. Den applikationsspecifikke .python-versionfil i den aktuelle mappe (hvis den findes). Du kan ændre den aktuelle katalogs .python-versionfil med pyenv localkommandoen.
  3. Den første .python-versionfil blev fundet (hvis nogen) ved at søge i hvert overordnet bibliotek, indtil den nåede roden til dit filsystem.
  4. Den globale version fil. Du kan ændre denne fil ved hjælp af pyenv globalkommandoen. Hvis den globale version-fil ikke er til stede, antager pyenv, at du vil bruge "systemet" Python. (Med andre ord, uanset hvilken version der kører, hvis pyenv ikke var i din PATH.)

Når du opretter et nyt projekt, der skal bruge Python 3.6.4, pyenv local 3.6.4vil det blive kørt i dets rodmappe. Dette ville både indstille versionen og oprette en .python-versionfil, så andre bidragyderes maskiner ville samle den op.

Den fulde beskrivelse af pyenvkommandoer er en bogmærke.

pyenv og venv

Når vi arbejder med Python 3.3+, ved vi nu både, hvordan man installerer og skifter mellem forskellige versioner af Python, og hvordan man opretter nye virtuelle miljøer.

Lad os som et eksempel sige, at vi oprettede et projekt, der skulle bruge Python 3.4.

Først kunne vi indstille vores lokale version ved hjælp af pyenv local 3.4.0.

Hvis vi derefter kørte, ville python3 -m venv example-projectet nyt virtuelt miljø blive oprettet under example-project, ved hjælp af vores lokalt aktiverede Python 3.4.0.

Vi aktiverer ved hjælp af source example-project/bin/activateog kan begynde at arbejde.

Dernæst kunne vi eventuelt dokumentere, at en samarbejdspartner skulle bruge python3.4 -m venv . Dette betyder, at selvom en samarbejdspartner ikke brugte pyenv, python3.4ville kommandoen fejle, hvis deres Python-version ikke var den samme store og mindre version (3 og 4), som vi havde til hensigt.

Alternativt kunne vi vælge blot at angive, at 3.4.0 skulle bruges, og instruere python3 -m venv . Hvis vi mener, at enhver ve rsion g reater end 3,4 er acceptabel, så vi også kan vælge at bruge python3i løbet python3.4, som om den samarbejdspartner var ved hjælp af 3,6 så ville de ellers også modtage en fejl. Dette er en projektspecifik beslutning.

pyenv-virtualenv

pyenvkan bruges til at installere både Python 2 og 3 versioner. Som vi har set, venver det dog begrænset til versioner af Python større end 3,3.

pyenv-virtualenver et værktøj til at skabe virtuelle miljøer integreret med pyenvog fungerer for alle versioner af Python. Det anbefales stadig at bruge den officielle Python, venvhvor det er muligt. Men hvis du for eksempel opretter et virtuelt miljø baseret på 2.7.13, så komplimenterer dette pyenv.

Det fungerer også godt i Anaconda og Miniconda condamiljøer, hvis du allerede bruger dem. Der virtualenvfindes også et kaldet værktøj . Det er ikke dækket her, men det er forbundet i slutningen.

Efter installationen pyenvkan den derefter installeres ved hjælp af Homebrew (eller alternativer) som sådan:

$ brew install pyenv-virtualenv

Næste i din .zshrc,, .bashrceller .bash_profile(afhængigt af hvilken skal du bruger) tilføj følgende i bunden:

eval "$(pyenv init -)" eval "$(pyenv virtualenv-init -)"

Dette gør det muligt pyenvat aktivere og deaktivere miljøer automatisk, når der flyttes mapper.

For at oprette et nyt virtuelt miljø skal du bruge:

$ pyenv virtualenv   // for example $ pyenv virtualenv 2.7.10 my-virtual-env-2.7.10

Eksisterende miljøer kan vises med:

$ pyenv virtualenvs

Aktiveret / deaktiveret med:

$ pyenv activate  $ pyenv deactivate

I skrivende stund vises activateadvarslen , når du bruger den prompt changing will be removed from future release. Dette forventes og refererer kun til det, (env-name)der vises i din shell, ikke brugen af ​​selve activatekommandoen.

Installationskrav fungerer som beskrevet i venv. I modsætning til i venven rm -rkommando er det ikke nødvendigt at fjerne et miljø, der uninstallfindes en kommando.

Afsluttende tanker

Mellem disse tre værktøjer har vi evnen til at samarbejde om ethvert projekt, uanset versionen af ​​Python eller de afhængigheder, der kræves. Vi ved også, hvordan man dokumenterer opsætningsinstruktioner, som andre kan bruge til ethvert projekt, vi arbejder på.

Vi kan også se ræsonnementet bag, hvilket sæt skal bruges, da ikke alle udviklere kræver alle tre.

Forhåbentlig var dette nyttigt og er en nyttig reference i kombination med nedenstående dokumentation.

Tak for læsningen! ?

Andre ting, jeg har udforsket:

  • Mocking ES og CommonJS moduler med jest.mock ()
  • En begyndervejledning til Amazons Elastic Container Service

Ressourcer

  • Python virtuelle miljøer: en primer
  • Forringes pyvenv
  • Python- venvdokumentation
  • venv vs. virtualenv
  • Hvad er forskellen mellem venv, pyvenv, pyenv, virtualenv, virtualenvwrapper, pipenv osv.?
  • Skal jeg installere pip?