håndtering af et lokalt Python-udviklingsmiljø er fortsat en udfordring, selv for erfarne udviklere. Mens der er veldokumenterede strategier for pakkehåndtering, er der et andet trin, der er nødvendigt for at sikre, at du kører den version af Python, du har brug for, når du har brug for det.

hvorfor betyder versionen af Python noget?

det er et mærkeligt koncept i starten, men programmeringssprog ændres som ethvert andet program. De har fejl, rettelser og opdateringer som alle dine foretrukne API ‘ er og andre programmer. Tilsvarende igen identificeres forskellige udgivelser med et trecifret tal kendt som en semantisk version.

pic.twitter.com/yt1Z2439W8 — Denny Peres (@dennyperes18) 28.maj 2019

i mange år var Python 2 den almindeligt anvendte hovedversion af programmeringssproget. I januar 2020 nåede Python 2 slutningen af livet, og kun Python 3 understøttes af sprogets kernevedligeholdere fra Da af. Python 3 udvikler sig støt og frigiver nye opdateringer regelmæssigt. Det gør det vigtigt for mig at regelmæssigt få disse opdateringer.

for nylig forsøgte jeg at køre et projekt på macOS, der var afhængig af Python 3.5.9, en version, som jeg ikke havde installeret på mit system. Det kan virke logisk at tro, at Python package manager pip kunne installere det*, men det var ikke tilfældet:

$ pip install python3.5.9
Collecting python3.5.9
ERROR: Could not find a version that satisfies the requirement python3.5.9 (from versions: none)
ERROR: No matching distribution found for python3.5.9

alternativt kunne jeg have hentet den version fra den officielle Python hjemmeside, men hvordan ville jeg køre den ind på min Mac sammen med min eksisterende version af Python? Angivelse af den version af Python, jeg har til hensigt at bruge hver gang jeg kører tolken (python3.7 eller python3.5 for eksempel) synes fejlbehæftet i bedste fald. Der skal være en bedre måde.

(en note om ovenstående: jeg ved, at dette ikke giver mening for krydret Python-Udvikler, men det gav mening for mig på det tidspunkt. Jeg vil gerne tale om, hvorfor jeg stadig synes, det skal.)

installation og opsætning af pyenv

heldigvis eksisterer pyenv for at omgå denne række kompleksiteter. For at starte, jeg havde brug for at installere pyenv. Jeg kunne klone og kompilere det selv fra kilden, men jeg foretrækker at administrere pakker som denne gennem Hjemmebryggepakkeadministratoren:

$ brew install pyenv

for at bruge versionen af Python gennem pyenv er det vigtigt at forstå skallens STIVARIABEL. Sti bestemmer, hvor skallen søger efter filer med navnet på kommandoen. Du skal sikre, at skallen finder den version af Python, der drives af pyenv, ikke den, der er installeret som standard (som ofte kaldes systemversionen). Hvis du ikke ændrer stien, er her resultatet:

$ which python
/usr/bin/python

det er systemversionen af Python.

for at konfigurere pyenv korrekt kan du køre følgende i Bash eller:

$ PATH=$(pyenv root)/shims:$PATH

nu, hvis du tjekker versionen af Python, vil du se, at det er den, der administreres af pyenv:

$ which python
/Users/my_username/.pyenv/shims/python

denne eksporterklæring (PATH=) ændres kun for denne shell-forekomst, så gør det til en permanent ændring, du skal tilføje den til dine dotfiles. Da macOS officielt er macOS ‘ standardskal, vil jeg fokusere på det. Tilføj den samme syntaks til~/.

$ echo 'PATH=$(pyenv root)/shims:$PATH' >> ~/.zshrc

nu hver gang vi kører en kommando i SSH, vil den bruge pyenv-versionen af Python. Bemærk, at jeg brugte enkelt citater med echo, så det ikke evaluerer og udvider kommandoerne.

den .så sørg for at kontrollere, hvad din shell er, og rediger de tilknyttede dotfiler. Hvis du har brug for at dobbelttjekke, hvad din standardskal er, kan du køre echo $SHELL. Hvis det er SSH, skal du bruge kommandoen ovenfor. Hvis du bruger Bash, skal du ændre ~/.sshrc til ~/.bashrc. Du kan dykke dybt ned i stiindstilling i pyenvs README, hvis du gerne vil lære mere.

brug af pyenv til at administrere Python-versioner

nu hvor pyenv er i kontrol, kan vi se, at det kun har systemet Python tilgængeligt for det:

$ pyenv versions
system

Som nævnt ovenfor vil du absolut ikke bruge denne version (Læs mere om hvorfor). Nu hvor pyenv er konfigureret korrekt, vil jeg have et par forskellige versioner af Python, som jeg regelmæssigt bruger.

der er en måde at se alle Python versioner tilgængelige fra alle de forskellige repositories pyenv har adgang til ved at køre pyenv install-list. Det er en lang, overvældende liste, der kan være nyttigt at gennemgå i fremtiden. For nu holder jeg mig til den seneste af hver dot-release (3.5.3.6.er den seneste) findes på Python Hent side. Med det i tankerne installerer jeg 3.5.9 og 3.8.0:

Dette vil tage et stykke tid, så få lidt te (eller læs et af linkene ovenfor). Det er interessant at bemærke, at output går gennem overførslen og opbygningen af den version af Python. For eksempel viser output, at filen kommer direkte fra Python.org.

Når alt er installeret, kan du konfigurere dine standardindstillinger. Jeg kan godt lide at leve i forkant, så jeg sætter min globale standard Python-version til den nyeste:

$ pyenv global 3.8.0

og den version er straks sat i min shell. For at bekræfte:

$ python -V 
Python 3.8.0

projektet, Jeg vil køre, fungerer kun med Python 3.5, så jeg indstiller versionen lokalt og bekræfter, at den er i brug:

$ pyenv local 3.5.9
$ python -V
Python 3.5.9

fordi jeg brugte den lokale indstilling med pyenv, tilføjede den en fil til min nuværende mappe for at spore disse oplysninger.

$ cat .python-version
3.5.9

nu Kan jeg endelig oprette et virtuelt miljø til det projekt, jeg ønsker, og være sikker på, at jeg kører den rigtige version af Python.

$ python -m venv venv
$ source ./venv/bin/activate
(venv) $ which python
/Users/mbbroberg/Develop/my_project/venv/bin/python

for at lære mere, tjek denne tutorial om styring af virtuelle miljøer på en Mac.

indpakning af

som standard kan det være en udfordring at køre flere Python-versioner. Jeg finder ud af at starte med pyenv sikrer, at jeg har de versioner af Python, jeg har brug for at køre, når jeg har brug for dem.