Många av oss arbetar på flera Python-projekt samtidigt. Flera projekt kan bero på olika versioner av samma bibliotek. Det här är ett problem. Även om du arbetar med ett enda projekt och du distribuerar det till produktion, kan det hända att du stöter på problem, eftersom systemets Python på din produktionsserver kan ändras på grund av OS-uppgradering eller säkerhetsuppdatering, och din applikation kan misslyckas som ett resultat. I allmänhet vill du ha full kontroll över Python-miljön i dina projekt. Ange virtuella miljöer ...
Grundtanken för en virtuell miljö är att ha en Python-tolk och dess webbplatspaket separerade från system ett. Du kan också ha många av dem. Det löser båda problemen. Du kan tilldela en separat virtuell miljö med egna beroenden för varje projekt och glömma konflikter med andra projekt och systemets Python.
I denna handledning lär du dig begreppen bakom virtuella miljöer och hur du skapar och använder dem, och du kommer att upptäcka olika alternativ för speciella situationer.
Virtualenv-paketet stöder detta koncept. Du kan installera virtualenv med pip installera virtualenv
.
När virtualenv har installerats kan du börja skapa virtuella miljöer. Låt oss skapa två miljöer som heter "venv_1" och "venv_2".
~> virtualenv ~ / venv_1 Använda reellt prefix '/usr/local/Cellar/python/2.7.10/Frameworks/Python.framework/Versions/2.7' Ny python körbar i /Users/gigi/venv_1/bin/python2.7 Även skapa körbar i / Användare / gigi / venv_1 / bin / python Installera setuptools, pip, wheel ... gjort. ~> virtualenv ~ / venv_2 Använda verkligt prefix '/usr/local/Cellar/python/2.7.10/Frameworks/Python.framework/Versions/2.7' Ny python körbar i /Users/gigi/venv_2/bin/python2.7 också skapa körbar i / Användare / gigi / venv_2 / bin / python Installera setuptools, pip, hjul ... gjort.
Låt oss se vad som hände.
~> ls -la ~ / venv_1 totalt 16 drwxr-xr-x 7 gigi-personal 238 mar 29 23:12. drwxr-xr-x + 254 gigi-personal 8636 mar 29 23: 12 ... lrwxr-xr-x 1 gigi-personal 79 mar 29 23:12 .Python -> /usr/local/Cellar/python/2.7.10/Frameworks/Python. ram / Versioner / 2.7 / Python drwxr-xr-x 16 gigi-personal 544 mar 29 23:12 bin drwxr-xr-x 3 gigi-personal 102 mar 29 23:12 inkluderar drwxr-xr-x 3 gigi-personal 102 mar 29 23: 12 lib -rw-r - r-- 1 gigi-personal 60 mar 29 23:12 pip-selfcheck.json
Inne i "bin" -katalogen hittar du några körbara och symlinker. Dessa inkluderar själva Python tolken, pip, easy_install och viktigast av allt några aktivera skript.
~> ls -la ~ / venv_1 / bin totalt 136 drwxr-xr-x 16 gigi-anställda 544 mar 29 23:12. drwxr-xr-x 7 gigi-personal 238 mar 29 23: 12 ... -rw-r - r-- 1 gigi-personal 2077 mar 29 23:12 aktivera -rw-r - r-- 1 gigi-personal 1019 mar 29 23 : 12 activate.csh -rw-r - r-- 1 gigi-personal 2217 mar 29 23:12 active.fish -rw-r - r-- 1 gigi-personal 1137 mar 29 23:12 activate_this.py -rwxr- xr-x 1 gigi-personal 249 mar 29 23:12 easy_install -rwxr-xr-x 1 gigi-personal 249 mar 29 23:12 easy_install-2.7 -rwxr-xr-x 1 gigi-personal 221 mar 29 23:12 pip -rwxr- xr-x 1 gigi-personal 221 mar 29 23:12 pip2 -rwxr-xr-x 1 gigi-personal 221 mar 29 23:12 pip2.7 lrwxr-xr-x 1 gigi-personal 9 mar 29 23:12 python -> python2. 7 -rwxr-xr-x 1 gigi-personal 2336 mar 29 23:12 python-config lrwxr-xr-x 1 gigi-personal 9 mar 29 23:12 python2 -> python2.7 -rwxr-xr-x 1 gigi-personal 12744 Mar 29 23:12 python2.7 -rwxr-xr-x 1 gigi-personal 228 mar 29 23:12 hjul
Aktiveringsskriptet är nyckeln. För att aktivera en viss virtuell miljö, källar du aktiveringsskriptet som i: source ~ / venv_1 / bin_activate
. Effekten ställer in en massa miljövariabler och ändrar prompten till namnet på den aktiverade virtuella miljön. Det lägger också till a avaktivera()
skalfunktion som återställer allt. När en virtuell miljö är aktiverad skriver du pytonorm
kommer att starta sin Python med dess beroende.
~> source ~ / venv_1 / bin / activate (venv_1) ~> vilken python / Användare / gigi / venv_1 / bin / python (venv_1) ~>
Låt oss avaktivera:
(venv_1) ~> avaktivera ~> vilken python / usr / local / bin / python
Om du har flera Python-tolkar installerade på dina system kan du ange vilken som ska användas för din virtuella miljö med hjälp av -p
alternativ. Här är en Python 3 virtuell miljö:
~> virtualenv ~ / venv_3 -p / usr / local / bin / python3 Running virtualenv med tolk / usr / local / bin / python3 Använda basprefix '/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework /Versions/3.5 "Ny python körbar i /Users/gigi/venv_3/bin/python3.5 Skapa även körbar i / Användare / gigi / venv_3 / bin / python Installera setuptools, pip ... done. ~> källa ~ / venv_3 / bin / aktivera (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 "help", "copyright", "credits" eller "license" för mer information. >>>
Virtualenv fungerar även på pypy.
~> virtualenv ~ / venv_pypy -p 'som pypy' Running virtualenv med tolk / usr / local / bin / pypy Ny pypy körbar i / Användare / gigi / venv_pypy / bin / pypy Installera setuptools, pip ... done. ~> källa ~ / venv_pypy / bin / aktivera (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 "help", "copyright", "credits" eller "license" för mer information. >>>>
Du kan växla direkt från en miljö till den andra utan att inaktivera först:
(venv_3) ~> källa ~ / venv_2 / bin / aktivera (venv_2) ~> vilken python / Users / gigi / venv_2 / bin / python
OK. Låt oss se hur du använder två olika versioner av samma paket i två olika virtuella miljöer. Detta är lika enkelt som att aktivera varje miljö och installera önskad version. Miljöerna är helt oberoende, så det faktum att det finns en annan version i en annan miljö är ett icke-problem.
Låt oss installera sh-paketet version 1.0.0 till "venv_1".
(venv_1) ~> pip installera sh == 1.0 Samla sh == 1.0.0 Hämta sh-1.0.tar.gz Bygghjul för insamlade paket: sh Running setup.py bdist_wheel för sh ... done Lagrat i katalogen: / Users / gigi / Bibliotek / Caches / pip / wheels / f9 / fb / a1 / 383f6dc2834b319a788a006d3ab7cc014ee852485f00b9e8c3 Framgångsrikt byggd sh Installera insamlade paket: sh Installerat framgångsrikt sh-1.0 (venv_1) ~> pip frysning | grep sh sh == 1,0
Låt oss byta till "venv_2" och installera version 1.11.
(venv_1) ~> källa ~ / venv_2 / bin / aktivera (venv_2) ~> pip installera sh == 1.11 Samla sh == 1.11 Hämta sh-1.11.tar.gz Bygghjul för insamlade paket: sh Kör setup.py bdist_wheel för sh ... done Sparade i katalogen: / Användare / gigi / Bibliotek / Caches / pip / wheels / ba / 4f / a5 / ec77d662c3bf38f564b5ab16f1f3dbb9575922826fe810961c Lyckades byggd sh Installera insamlade paket: sh Installerat framgångsrikt sh-1.11 (venv_2) ~> pip frysning | grep sh sh == 1,11
Låt oss nu byta tillbaka till "venv_1" och verifiera att dess version av sh-paketet fortfarande är 1.0.
(venv_2) ~> källa ~ / venv_1 / bin / aktivera (venv_1) ~> pip frysa | grep sh sh == 1.0 (venv_1) ~>
Allt som aktiverar, avaktiverar och byter kan bli gammalt efter ett tag. Om du klarar av många virtuella miljöer kan det komma ur kontroll. Det är där virtualenvwrapper kommer in. Virtualenvwrapper låter dig lista, skapa, ta bort och kopiera virtuella miljöer. Det låter dig också enkelt byta miljöer.
Här är alla kommandon:
~> virtualenvwrapper virtualenvwrapper är en uppsättning tillägg till Ian Bickings virtuella verktyg. Utvidgningarna innehåller inslag för att skapa och ta bort virtuella miljöer och på annat sätt hantera ditt arbetsflöde, vilket gör det enklare att arbeta på mer än ett projekt åt gången utan att införa konflikter i deras beroende. Mer information finns i dokumentationen: http://virtualenvwrapper.readthedocs.org/en/latest/command_ref.html Kommandon tillgängliga: add2virtualenv: lägg till katalog till importvägen allvirtualenv: kör ett kommando i alla virtualenvs cdproject: byt katalog till det aktiva projektet cdsitepackages: byt till katalogen för webbplatspaket cdvirtualenv: byt till katalogen $ VIRTUAL_ENV cpvirtualenv: duplicera namnet virtualenv för att skapa en ny lssitepackage: lista innehållet i webbplatspaketet katalogen lsvirtualenv: list virtualenvs mkproject: skapa en ny projektkatalog och dess associerade virtualenv mktmpenv: skapa en tillfällig virtualenv mkvirtualenv: Skapa en ny virtualenv i $ WORKON_HOME rmvirtualenv: Ta bort ett virtualenv setvirtualenvprojekt: associera en projektkatalog med virtualenv showvirtualenv: visa detaljer för en enda virtualenv toggleglobalsitepackage: vrid åtkomst till global webbplats -packages on / off virtualenvwrapper: visa detta hjälpmeddelande wipeenv: ta bort alla paket installerade i nuvarande virtualenv workon: lista eller ändra virtuella virtuella
Jag använder ganska mycket två kommandon: mkvirtualenv
och jobba på
. Alla virtuella miljöer skapas under ~ / .Virtualenvironments
.
Så här skapar du en ny virtuell miljö:
~> mkvirtualenv venv Ny python körbar i venv / bin / python2.7 Skapa också körbar i venv / bin / python Installera setuptools, pip ... done. (venv) ~>
Det här liknar virtualenv, men du anger inte en katalog, bara ett namn. Din nya miljö är här:
(venv) ~> träd -L 2 ~ / .virtualenvs / venv / /Users/gigi/.virtualenvs/venv/ ├── bin │ ├── aktivera │ ├── activate.csh │ ├── activate.fish │ ├── active_this.py │ ├── easy_install │ ├── easy_install-2.7 │ ├── get_env_details │ ├── pip │ ├── pip2 │ ├── pip2.7 │ ├── postaktivera │ ├── postdeaktivera │ ├── förprogrammera │ ├── predeaktivera │ ├── 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
För att växla mellan miljöer använder du jobba på
kommando, som utan argument bara listar alla virtuella miljöer. Jag har ett par:
(venv) ~> workon acme_server conman curr-gen nupic over-achiever pandas prime_hunter pypy quote-service venv arbete (venv) ~> workon conman (conman) ~>
Virtualenv-Burrito är ett projekt för att installera både virtualenv och virtualenvwrapper i ett kommando.
Venv-modulen fanns till Python 3.3 och ger inbyggd virtuell miljö skapande och hantering precis som virtualenv. Kommandot att skapa virtuella miljöer är pyenv
. Annars är det ungefär som virtualenv.
Virtuella miljöer är mycket användbara för att isolera beroenden mellan olika projekt. Men det sträcker sig inte till inbyggda bibliotek. Många C-förlängningar beror på särskilda versioner av inbyggda bibliotek, och de kan inte vara virtuella miljöspecifika.
Conda kan ta itu med detta problem. Det är ett pakethanteringssystem som hanterar alla beroenden, inte bara Pythonberoende. Det kan till och med användas för förpackning av icke-Python-programvara.
Behöver du använda virtuella miljöer? Inte riktigt. Om du av någon anledning inte är förtjust i magiken i virtuella miljöer, finns det andra alternativ.
Funktionen hos en virtuell miljö är ganska enkel. Om du behöver total kontroll kan du bara göra det själv och kopiera exakt delmängden av verktyg och paket som du vill ha i en målkatalogstruktur, skapa några miljövariabler och du är bra att gå.
Om du bager dina program till en dockningsbehållare eller en molnbild kommer det bara att finnas ett projekt, och du kanske inte behöver en virtuell miljö i mitten. Du kan bara bygga upp på systemet Python, vara säker på att det inte kommer att ändras.
Om allt du bryr dig om är att testa din kod under olika tolkar och miljöer, så kan Tox göra allt tungt för dig. Den kommer fortfarande använda virtuella miljöer under omslaget, men du behöver inte hantera dem.
Det finns några bästa metoder för förpackning och virtuell miljö som har uppstått över tiden för robusta Python-system.
Pinning innebär att specificera exakt versionerna av dina beroende. Om en ny version kommer ut och du installerar din applikation på en ny server, använder du fortfarande den version du testat mot och det fungerar, inte den senaste och bästa. Det finns en nackdel här - du måste explicit uppgradera versioner om du vill fortsätta med de framsteg som gjorts av dina beroende - men det är vanligtvis värt det.
Att lita på systemversionen är dålig övning eftersom det finns andra verktyg som är beroende av det, och om du börjar uppgradera systempaket kan du bryta dem. Du kan också påverkas av säkerhetsuppdateringar som ändrar systempaket eller i allmänhet om du vill uppgradera ditt operativsystem kan du upptäcka att systemet Python nu är annorlunda.
PyPI kan vara nere. Om du behöver baka en ny bild och inte har tillgång till PyPI, har du problem. Devpi är ett bra alternativ för att undvika frustration.
Det finns många alternativ för hantering av flera Python-projekt på samma maskin utan konflikter. Ta reda på vilket alternativ som är bäst för dig och använd det. Det är snabbt och enkelt att skapa virtuella miljöer. Tveka inte att dra nytta av detta användbara verktyg. Om du har speciella krav finns det också många lösningar.