Mange av oss jobber på flere Python-prosjekter samtidig. Flere prosjekter kan avhenge av forskjellige versjoner av samme bibliotek. Dette er et problem. Selv om du arbeider med et enkelt prosjekt, og du distribuerer det til produksjon, kan det føre til problemer, fordi systemets Python på produksjonsserveren din kan endres på grunn av OS-oppgradering eller sikkerhetsoppdatering, og programmet kan mislykkes som et resultat. Generelt vil du ha full kontroll over Python-miljøet i prosjektene dine. Skriv inn virtuelle miljøer ...
Den grunnleggende ideen om et virtuelt miljø er å ha en Python tolk og dens nettstedspakker skilt fra system en. Også, du kan ha mange av dem. Det løser begge problemene. Du kan tilordne et eget virtuelt miljø med sine egne avhengigheter for hvert prosjekt og glemme konflikter med andre prosjekter og systemets Python.
I denne opplæringen lærer du konseptene bak virtuelle miljøer og hvordan du oppretter og bruker dem, og du vil finne ulike alternativer for spesielle situasjoner..
Virtualenv-pakken støtter dette konseptet. Du kan installere virtualenv ved hjelp av pip installere virtualenv
.
Når virtualenv er installert, kan du begynne å lage virtuelle miljøer. La oss lage to miljøer kalt "venv_1" og "venv_2".
~> virtualenv ~ / venv_1 Bruke ekte prefix '/usr/local/Cellar/python/2.7.10/Frameworks/Python.framework/Versions/2.7' Ny python kjørbar i /Users/gigi/venv_1/bin/python2.7 Også skaper kjørbar i / Brukere / gigi / venv_1 / bin / python Installere setuptools, pip, hjul ... ferdig. ~> virtualenv ~ / venv_2 Bruk av ekte prefiks '/usr/local/Cellar/python/2.7.10/Frameworks/Python.framework/Versions/2.7' Ny python kjørbar i /Users/gigi/venv_2/bin/python2.7 Også skaper kjørbar i / Brukere / gigi / venv_2 / bin / python Installere setuptools, pip, hjul ... ferdig.
La oss se hva som skjedde.
~> ls -la ~ / venv_1 totalt 16 drwxr-xr-x 7 gigi-ansatte 238 mar 29 23:12. drwxr-xr-x + 254 gigi stab 8636 Mar 29 23: 12 ... lrwxr-xr-x 1 gigi-stab 79 Mar 29 23:12 .Python -> /usr/local/Cellar/python/2.7.10/Frameworks/Python. ramme / Versjoner / 2.7 / Python drwxr-xr-x 16 gigi-ansatte 544 Mar 29 23:12 bin drwxr-xr-x 3 gigi-ansatte 102 Mar 29 23:12 inkludere drwxr-xr-x 3 gigi-ansatte 102 Mar 29 23: 12 lib -rw-r - r-- 1 gigi-stab 60 mar 29 23:12 pip-selfcheck.json
I underkataloget "bin" finner du noen kjørbare og symlinker. Disse inkluderer Python tolk selv, pip, easy_install, og viktigst noen få aktiverte skript.
~> ls -la ~ / venv_1 / bin totalt 136 drwxr-xr-x 16 gigi-ansatte 544 Mar 29 23:12. drwxr-xr-x 7 gigi-ansatte 238 mar 29 23: 12 ... -rw-r - r-- 1 gigi-ansatte 2077 mar 29 23:12 aktivere -rw-r - r-- 1 gigi-ansatte 1019 mar 29 23 : 12 active.csh -rw-r - r-- 1 gigi-stab 2217 Mar 29 23:12 active.fish -rw-r - r-- 1 gigi-stab 1137 Mar 29 23:12 active_this.py -rwxr- xr-x 1 gigi-stab 249 mar 29 23:12 easy_install -rwxr-xr-x 1 gigi-stab 249 mar 29 23:12 easy_install-2.7 -rwxr-xr-x 1 gigi-ansatte 221 mar 29 23:12 pip -rwxr- xr-x 1 gigi-stab 221 mar 29 23:12 pip2 -rwxr-xr-x 1 gigi-stab 221 mar 29 23:12 pip2.7 lrwxr-xr-x 1 gigi-stab 9 mar 29 23:12 python -> python2. 7 -rwxr-xr-x 1 gigi-stab 2336 mar 29 23:12 python-config lrwxr-xr-x 1 gigi-stab 9 mar 29 23:12 python2 -> python2.7 -rwxr-xr-x 1 gigi-stab 12744 Mar 29 23:12 python2.7 -rwxr-xr-x 1 gigi-stab 228 mar 29 23:12 hjul
Aktiveringsskriptet er nøkkelen. For å aktivere et bestemt virtuelt miljø, kilde du aktiveringsskriptet, som i: kilde ~ / venv_1 / bin_activate
. Effekten er å sette en masse miljøvariabler og endre spørringen til navnet på det aktiverte virtuelle miljøet. Det legger også til a deaktivere ()
shell funksjon som vil tilbakestille alt. Når et virtuelt miljø er aktivert, skriver du python
vil starte sin Python med sine avhengigheter.
~> kilde ~ / venv_1 / bin / aktiver (venv_1) ~> hvilken python / Brukere / gigi / venv_1 / bin / python (venv_1) ~>
La oss deaktivere:
(venv_1) ~> deaktivere ~> hvilken python / usr / local / bin / python
Hvis du har flere Python-tolker installert på systemene dine, kan du spesifisere hvilken som skal brukes til ditt virtuelle miljø ved hjelp av -p
alternativ. Her er et Python 3 virtuelt miljø:
~> virtualenv ~ / venv_3 -p / usr / local / bin / python3 Kjører virtualenv med tolk / usr / local / bin / python3 Bruke base prefix '/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework /Versions/3.5 'Ny python kjørbar i /Users/gigi/venv_3/bin/python3.5 Lag også kjørbar i / Brukere / gigi / venv_3 / bin / python Installere setuptools, pip ... ferdig. ~> kilde ~ / venv_3 / bin / aktivere (venv_3) ~> python Python 3.5.1 (standard, jan 9 2016, 19:28:52) [GCC 4.2.1 Kompatibel Apple LLVM 7.0.0 (clang-700.1.76 )] på darwin Skriv "hjelp", "copyright", "credits" eller "lisens" for mer informasjon. >>>
Virtualenv fungerer selv på pypy.
~> virtualenv ~ / venv_pypy -p 'som pypy' Running virtualenv med tolk / usr / local / bin / pypy Ny pypy kjørbar i / Brukere / gigi / venv_pypy / bin / pypy Installere setuptools, pip ... ferdig. ~> kilde ~ / venv_pypy / bin / activate (venv_pypy) ~> python Python 2.7.10 (5f8302b8bf9f53056e40426f10c72151564e5b19, Feb 11 2016, 20:39:39) [PyPy 4.0.1 med GCC 4.2.1 Kompatibel Apple LLVM 7.0.2 ( clang-700.1.81)] på darwin Skriv "hjelp", "copyright", "kreditter" eller "lisens" for mer informasjon. >>>>
Du kan bytte direkte fra ett miljø til det andre uten å deaktivere først:
(venv_3) ~> kilde ~ / venv_2 / bin / aktiver (venv_2) ~> hvilken python / Brukere / gigi / venv_2 / bin / python
OK. La oss se hvordan du bruker to forskjellige versjoner av samme pakke i to forskjellige virtuelle miljøer. Dette er så enkelt som å aktivere hvert miljø og installere ønsket versjon. Miljøene er helt uavhengige, så det faktum at det finnes en annen versjon i et annet miljø er et ikke-problem.
La oss installere sh pakke versjon 1.0.0 til "venv_1".
(venv_1) ~> pip install sh == 1.0 Samle sh == 1.0.0 Nedlasting sh-1.0.tar.gz Bygghjul for samlepakker: sh Kjører setup.py bdist_wheel for sh ... ferdig Lagret i katalog: / Brukere / gigi / Bibliotek / Caches / pip / wheels / f9 / fb / a1 / 383f6dc2834b319a788a006d3ab7cc014ee852485f00b9e8c3 Vellykket bygget sh Installering av innsamlede pakker: sh Vellykket installert sh-1.0 (venv_1) ~> pip fryser | grep sh sh == 1.0
La oss bytte til "venv_2" og installere versjon 1.11.
(venv_1) ~> kilde ~ / venv_2 / bin / aktiver (venv_2) ~> pip installasjon sh == 1,11 Samle sh == 1.11 Last ned sh-1.11.tar.gz Bygghjul for samlepakker: sh Kjører setup.py bdist_wheel for sh ... gjort Lagret i katalogen: / Brukere / gigi / Bibliotek / Caches / pip / wheels / ba / 4f / a5 / ec77d662c3bf38f564b5ab16f1f3dbb9575922826fe810961c Vellykket bygget sh Installering av samlepakker: sh Installert vellykket sh-1.11 (venv_2) ~> pip fryser | grep sh sh == 1,11
La oss nå bytte tilbake til "venv_1" og bekrefte at versjonen av sh-pakken fortsatt er 1,0.
(venv_2) ~> kilde ~ / venv_1 / bin / aktiver (venv_1) ~> pip fryser | grep sh sh == 1.0 (venv_1) ~>
Alt som aktiverer, deaktiverer og bytter kan bli gammelt etter en stund. Hvis du klarer mange virtuelle miljøer, kan det komme ut av kontroll. Det er der virtualenvwrapper kommer inn. Virtualenvwrapper lar deg liste, lage, slette og kopiere virtuelle miljøer. Det lar deg også bytte miljøer enkelt.
Her er alle kommandoene:
~> virtualenvwrapper virtualenvwrapper er et sett med utvidelser til Ian Bickings virtuelle verktøy. Utvidelsene inkluderer wrappers for å lage og slette virtuelle miljøer og ellers administrere utviklings arbeidsflyten, noe som gjør det lettere å jobbe på mer enn ett prosjekt om gangen uten å innføre konflikter i deres avhengigheter. For mer informasjon vennligst se dokumentasjonen: http://virtualenvwrapper.readthedocs.org/en/latest/command_ref.html Kommandoer tilgjengelig: add2virtualenv: legg til katalog til importbanen allvirtualenv: Kjør en kommando i alle virtualenvs cdproject: bytt katalog til det aktive prosjektet cdsitepackages: bytt til nettstedet pakker katalogen cdvirtualenv: bytt til $ VIRTUAL_ENV katalogen cpvirtualenv: dupliser den navngitte virtualenv for å lage en ny lssitepackages: liste innholdet i nettstedet pakker katalogen lsvirtualenv: list virtualenvs mkproject: opprett en ny prosjektkatalog og tilhørende virtualenv mktmpenv: opprett en midlertidig virtualenv mkvirtualenv: Opprett en ny virtualenv i $ WORKON_HOME rmvirtualenv: Fjern et virtualenv setvirtualenvproject: knytt et prosjektkatalog med en virtualenv showvirtualenv: vis detaljer om en enkelt virtualenv toggleglobalsitepackages: snu tilgang til globalt nettsted -pakker på / av virtualenvwrapper: vis denne hjelpemeldingen wipeenv: fjern alle pakkene som er installert i den nåværende virtualenv workon: liste eller endre virtuelle arbeidsplasser
Jeg bruker ganske mye to kommandoer: mkvirtualenv
og jobbe med
. Alle de virtuelle miljøene er opprettet under ~ / .Virtualenvironments
.
Slik lager du et nytt virtuelt miljø:
~> mkvirtualenv venv Ny python kjørbar i venv / bin / python2.7 Opprett også kjørbar i venv / bin / python Installere setuptools, pip ... ferdig. (venv) ~>
Dette ligner på virtualenv, men du angir ikke en katalog, bare et navn. Ditt nye miljø er her:
(venv) ~> tree -L 2 ~ / .virtualenvs / venv / /Users/gigi/.virtualenvs/venv/ ├── bin │ ├── aktivere │ ├── activate.csh │ ├── activate.fish │ ├── active_this.py │ ├── easy_install │ ├── easy_install-2.7 │ ├── get_env_details │ ├── pip │ ├── pip2 │ ├── pip2.7 │ ├── postaktivere │ ├── postdeaktivere │ ├── forhåndsaktivere │ ├── predeaktivere │ ├── python -> python2.7 │ ├── python2 -> python2.7 │ └── python2.7 ├── include │ └── python2.7 -> /usr/local/Cellar/python/2.7.10/Frameworks/Python.framework/Versions/2.7/include/python2.7 └── lib └── python2.7
For å bytte mellom miljøer bruker du jobbe med
kommando, som uten argumenter bare viser alle virtuelle miljøer. Jeg har ganske mange:
(venv) ~> workon acme_server conman curr-gen nupic over-achiever pandas prime_hunter pypy quote-service venv work (venv) ~> workon conman (conman) ~>
Virtualenv-Burrito er et prosjekt for å installere både virtualenv og virtualenvwrapper i en kommando.
Venv-modulen ble lagt til Python 3.3 og gir innebygd virtuell miljøopprettelse og -administrasjon, akkurat som virtualenv. Kommandoen for å lage virtuelle miljøer er pyenv
. Ellers er det ganske lik virtualenv.
Virtuelle miljøer er svært nyttige for å isolere avhengigheter mellom ulike prosjekter. Men det strekker seg ikke til innfødte biblioteker. Mange C-utvidelser er avhengige av bestemte versjoner av innfødte biblioteker, og de kan ikke være virtuelle miljøspesifikke.
Conda kan takle dette problemet. Det er et pakkehåndteringssystem som håndterer alle avhengigheter, ikke bare Python-avhengigheter. Det kan til og med brukes til å pakke inn ikke-Python-programvare.
Må du bruke virtuelle miljøer? Ikke egentlig. Hvis du av en eller annen grunn ikke er glad i det magiske av virtuelle miljøer, er det andre alternativer.
Funksjonen til et virtuelt miljø er ganske enkelt. Hvis du trenger total kontroll, kan du bare gjøre det selv og kopiere nøyaktig delmengden av verktøy og pakker du vil ha i en målkatalogstruktur, sette opp noen miljøvariabler, og du er god til å gå.
Hvis du baker programmene dine til en dokkerbeholder eller et skybilde, vil det bare være ett prosjekt, og du trenger kanskje ikke et virtuelt miljø i midten. Du kan bare bygge på toppen av systemet Python, være sikker på at den ikke vil bli endret.
Hvis alt du bryr deg om, er å teste koden din under forskjellige tolker og miljøer, kan Tox gjøre alt tungt løft for deg. Den vil fortsatt bruke virtuelle miljøer under dekslene, men du trenger ikke å håndtere dem.
Det er noen pakker og virtuelle miljø-best practices som har kommet over tid for robuste Python-systemer.
Pinning betyr å spesifisere nøyaktig versjoner av dine avhengigheter. Hvis en ny versjon kommer ut og du installerer programmet på en ny server, vil du fortsatt bruke den versjonen du testet mot, og som fungerer, og ikke den nyeste og største. Det er en ulempe her - du må eksplisitt oppgradere versjoner hvis du vil holde tritt med fremdriften av dine avhengigheter - men det er vanligvis verdt det.
Å stole på systemversjonen er dårlig praksis fordi det er andre verktøy som er avhengige av det, og hvis du begynner å oppgradere systempakker, kan du ødelegge dem. Du kan også bli påvirket av sikkerhetsoppdateringer som endrer systempakker, eller generelt hvis du vil oppgradere operativsystemet ditt, kan du oppleve at systemet Python nå er annerledes.
PyPI kan være nede. Hvis du trenger å bake et nytt bilde og ikke får tilgang til PyPI, er du i trøbbel. Devpi er et godt alternativ for å unngå frustrasjon.
Det er mange alternativer for å administrere flere Python-prosjekter på samme maskin uten konflikter. Finn ut hvilket alternativ som passer best for deg og bruk det. Det er raskt og enkelt å lage virtuelle miljøer. Ikke nøl med å dra nytte av dette nyttige verktøyet. Hvis du har spesielle krav, er det også mange løsninger.