Python 3.3 zawiera w swojej standardowej bibliotece nowy pakiet venv. Co robi i czym różni się od wszystkich innych pakietów, które wydają się pasować do wyrażenia regularnego (py)?(v|virtual|pip)?env?

Pakiety PyPI spoza standardowej biblioteki:

• virtualenvjest bardzo popularnym narzędziem, które tworzy izolowane środowiska Python dla bibliotek Python. Jeśli nie znasz tego narzędzia, zdecydowanie polecam jego naukę, ponieważ jest to bardzo przydatne narzędzie, a ja dokonam porównań z pozostałą częścią tej odpowiedzi.

  Działa, instalując kilka plików w katalogu (np . env/:), a następnie modyfikując PATHzmienną środowiskową, aby poprzedzała ją niestandardowym binkatalogiem (np env/bin/.:). Dokładna kopia pliku binarnego pythonlub python3jest umieszczana w tym katalogu, ale Python jest zaprogramowany tak, aby najpierw szukał bibliotek względem ścieżki w katalogu środowiska. Nie jest częścią standardowej biblioteki Pythona, ale jest oficjalnie pobłogosławiony przez PyPA (Python Packaging Authority). Po aktywacji możesz zainstalować pakiety w środowisku wirtualnym za pomocą pip.

• pyenvsłuży do izolowania wersji Pythona. Na przykład możesz przetestować swój kod pod kątem Pythona 2.7, 3.6, 3.7 i 3.8, więc będziesz potrzebował sposobu na przełączanie się między nimi. Po aktywacji poprzedza PATHzmienną środowiskową słowem ~/.pyenv/shims, w którym znajdują się specjalne pliki pasujące do poleceń Pythona ( python, pip). To nie są kopie poleceń dostarczanych przez Python; są to specjalne skrypty, które na bieżąco decydują, którą wersję Pythona uruchomić w oparciu o PYENV_VERSIONzmienną środowiskową, .python-versionplik lub ~/.pyenv/versionplik. pyenvułatwia także pobieranie i instalowanie wielu wersji Pythona za pomocą polecenia pyenv install.

• pyenv-virtualenvjest wtyczką dla pyenvtego samego autora, co pyenv, aby umożliwić ci korzystanie pyenvi virtualenvjednocześnie wygodne. Jeśli jednak używasz języka Python 3.3 lub nowszego, pyenv-virtualenvspróbujesz uruchomić, python -m venvjeśli jest dostępny, zamiast virtualenv. Możesz używać virtualenvi pyenvrazem bez pyenv-virtualenv, jeśli nie chcesz funkcji wygody.

• virtualenvwrapperto zestaw rozszerzeń virtualenv(patrz dokumenty ). Daje ci polecenia takie jak mkvirtualenv, lssitepackagesa zwłaszcza workondo przełączania między różnymi virtualenvkatalogami. To narzędzie jest szczególnie przydatne, jeśli chcesz mieć wiele virtualenvkatalogów.

• pyenv-virtualenvwrapperJest to plugin do pyenvtego samego autora, jak pyenvi wygodnie zintegrować virtualenvwrappersię pyenv.

• pipenvma na celu łączyć Pipfile, pipa virtualenvdo jednego polecenia w linii poleceń. virtualenvKatalog zwykle zostaje umieszczone w ~/.local/share/virtualenvs/XXX, z XXXbycia hash ścieżce katalogu projektu. Różni się to od tego virtualenv, gdzie katalog zazwyczaj znajduje się w bieżącym katalogu roboczym. pipenvjest przeznaczony do użycia podczas tworzenia aplikacji w języku Python (w przeciwieństwie do bibliotek). Istnieją alternatywy pipenv, takie jak poetry, których nie wymienię tutaj, ponieważ to pytanie dotyczy tylko pakietów o podobnej nazwie.

Biblioteka standardowa:

• pyvenvto skrypt dostarczany z Pythonem 3, ale przestarzały w Pythonie 3.6, ponieważ miał problemy (nie wspominając o mylącej nazwie). W Pythonie 3.6+ dokładny odpowiednik to python3 -m venv.

• venvto pakiet dostarczany z Pythonem 3, który można uruchomić python3 -m venv(chociaż z jakiegoś powodu niektóre dystrybucje dzielą go na osobny pakiet dystrybucyjny, taki jak python3-venvna Ubuntu / Debian). Służy temu samemu celowi virtualenv, ale ma tylko podzbiór jego funkcji ( patrz porównanie tutaj ). virtualenvnadal jest bardziej popularny niż venv, zwłaszcza, że ​​pierwszy obsługuje zarówno Python 2, jak i 3.

Zalecenie dla początkujących:

To jest moja osobista rekomendacja dla początkujących: zacznij od nauki virtualenvi pipnarzędzi, które działają zarówno z Pythonem 2, jak i 3 oraz w różnych sytuacjach, i wybierz inne narzędzia, gdy zaczniesz ich potrzebować.

Po prostu unikałbym używania programu virtualenvpo Python3.3 + i zamiast tego używałbym standardowej biblioteki dostarczonej venv. Aby utworzyć nowe środowisko wirtualne, wpisz:

$ python3 -m venv <MYVENV>  

virtualenvpróbuje skopiować plik binarny Python do katalogu bin środowiska wirtualnego. Jednak nie aktualizuje łączy plików bibliotek osadzonych w tym pliku binarnym, więc jeśli zbudujesz Pythona ze źródła w katalogu niesystemowym o względnych nazwach ścieżek, plik binarny Pythona ulegnie awarii. Ponieważ w ten sposób tworzysz kopię Pythona do dystrybucji, jest to duża wada. BTW, aby sprawdzić osadzone łącza plików bibliotek w OS X, użyj otool. Na przykład w środowisku wirtualnym wpisz:

$ otool -L bin/python
python:
    @executable_path/../Python (compatibility version 3.4.0, current version 3.4.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0)

W związku z tym unikałbym virtualenvwrapperi pipenv. pyvenvjest przestarzałe. pyenvwydaje się być używany często tam, gdzie virtualenvjest używany, ale trzymałbym się z dala od niego również, ponieważ myślę, że venvrobi to, co pyenvjest zbudowane.

venvtworzy środowiska wirtualne w powłoce, które są świeże i w piaskownicy , z bibliotekami instalowanymi przez użytkownika i jest bezpieczne dla wielu Pythona . Świeżo, ponieważ środowiska wirtualne zaczynają się tylko od standardowych bibliotek dostarczanych z Pythonem, musisz zainstalować wszystkie inne biblioteki od nowa, pip installgdy środowisko wirtualne jest aktywne. Piaskownica, ponieważ żadna z tych nowych instalacji bibliotek nie jest widoczna poza środowiskiem wirtualnym, dzięki czemu można usunąć całe środowisko i rozpocząć od nowa bez obawy o wpływ na podstawową instalację Pythona. Biblioteki instalowane przez użytkownika, ponieważ folder docelowy środowiska wirtualnego jest tworzony bezsudow jakimś katalogu, który już posiadasz, więc nie będziesz potrzebować sudouprawnień do instalowania w nim bibliotek. Wreszcie jest bezpieczny dla wielu Pythona , ponieważ po aktywacji środowisk wirtualnych powłoka widzi tylko wersję Pythona (3.4, 3.5 itd.), Która została użyta do zbudowania tego środowiska wirtualnego.

pyenvjest podobny do venvtego, że pozwala zarządzać wieloma środowiskami Pythona. Jednak pyenvnie możesz wygodnie wycofać instalacji bibliotek do stanu początkowego i prawdopodobnie będziesz potrzebować adminuprawnień do aktualizacji bibliotek. Myślę więc, że najlepiej też użyć venv.

W ciągu ostatnich kilku lat znalazłem wiele problemów w systemach kompilacji (pakiety emacs, samodzielne konstruktory aplikacji python, instalatory ...), które ostatecznie sprowadzają się do problemów virtualenv. Myślę, że Python będzie lepszą platformą, kiedy wyeliminujemy tę dodatkową opcję i użyjemy tylko venv.

Poszedłem do pipenvdziury królika ( to jest naprawdę głęboka i ciemna dziura ... ), a ponieważ ostatnia odpowiedź jest ponad 2 lata temu , uznałem, że warto zaktualizować dyskusję o najnowsze osiągnięcia dotyczące tematu wirtualnych kopert I znalazłem.

ZRZECZENIE SIĘ:

Ta odpowiedź NIE dotyczy kontynuowania szalejącej debaty na temat zalet pipenv kontra venv jako rozwiązań kopertowych - nie popieram żadnego z nich . Chodzi o PyPA popierając sprzecznych norm i jak przyszły rozwój virtualenv obietnic negować dokonywania albo / albo wybór między nimi w ogóle. Skoncentrowałem się na tych dwóch narzędziach właśnie dlatego, że są namaszczone przez PyPA .

venv

Jak zauważa OP, venv jest narzędziem do wirtualizacji środowisk. NIE rozwiązanie strony trzeciej, ale natywne narzędzie. PyPA popiera venv do tworzenia WIRTUALNYCH KOPERT : „ Zmieniono w wersji 3.5: Teraz zaleca się użycie venv do tworzenia środowisk wirtualnych ”.

pipenv

pipenv - podobnie jak venv - może być wykorzystywany do tworzenia wirtualnych kopert, ale dodatkowo umożliwia zarządzanie pakietami i sprawdzanie podatności . Zamiast używaćrequirements.txt,pipenvzapewnia zarządzanie pakietami za pomocą Pipfile . Ponieważ PyPA popiera pipenv do ZARZĄDZANIA PAKIETAMI , wydaje się, że sugerujepipfileto zastąpienierequirements.txt.

JEDNAK : pipenv używa virtualenv jako narzędzia do tworzenia wirtualnych kopert, a NIE venv, który jest popierany przez PyPA jako narzędzie do tworzenia wirtualnych kopert.

Sprzeczne normy:

Więc jeśli ustalenie rozwiązania wirtualnej koperty nie było wystarczająco trudne, mamy teraz PyPA zatwierdzające dwa różne narzędzia, które używają różnych rozwiązań wirtualnej koperty. Szalejącą debatę Github na temat Venv vs. Virtualenv, która podkreśla ten konflikt, można znaleźć tutaj .

Rozwiązanie konfliktu:

Debata na Github, o której mowa w powyższym linku, ukierunkowała rozwój virtualenv w kierunku dostosowania venv w przyszłych wydaniach :

wolę wbudowany venv: jeśli docelowy python ma venv, stworzymy środowisko za pomocą tego (a następnie wykonamy na nim kolejne operacje, aby ułatwić inne oferowane przez nas gwarancje)

Wniosek:

Wygląda więc na to, że w przyszłości nastąpi pewna zbieżność między dwoma rywalizującymi rozwiązaniami wirtualnej koperty, ale na razie pipenv - z którego korzysta virtualenv- różni się znacznievenv .

Biorąc pod uwagę problemy, które rozwiązuje pipenv, oraz fakt, że PyPA udzielił błogosławieństwa, wydaje się , że ma przed sobą świetlaną przyszłość. A jeśli virtualenv dostarcza na proponowanych celów rozwojowych, wybierając wirtualny rozwiązanie koperty nie powinny już być przypadek albo pipenv LUB venv .

Aktualizacja z kwietnia 2020 r

Szukałem tego samego, kiedy natknąłem się na ten post . Myślę, że to pytanie o to, jakiego narzędzia użyć, jest dość mylące i trudne dla nowych użytkowników Pythona, takich jak ja. To jest bezpośrednio ze strony internetowej PyPA dotyczącej pipenv:

Chociaż ten samouczek obejmuje projekt pipenv jako narzędzie, które koncentruje się przede wszystkim na potrzebach rozwoju aplikacji Python, a nie na rozwoju biblioteki Python, sam projekt obecnie pracuje nad kilkoma problemami związanymi z procesem i konserwacją, które uniemożliwiają opublikowanie poprawek błędów i nowych funkcji ( wraz z upływem całego 2019 r. bez nowej wersji). Oznacza to, że w najbliższym czasie pipenv nadal cierpi z powodu kilku dziwactw i problemów z wydajnością bez wyraźnego harmonogramu rozwiązywania tych problemów.

Chociaż tak jest nadal, opiekunowie projektów prawdopodobnie będą chcieli zbadać inne narzędzia do zarządzania zależnością aplikacji do użytku zamiast lub razem z pipenv.

Zakładając, że wydanie pipenv z kwietnia 2020 r. Odbędzie się zgodnie z planem, a późniejsze wydanie również pozostanie na dobrej drodze, wówczas to zastrzeżenie w samouczku zostanie usunięte. Jeśli te wersje nie będą działać zgodnie z planem, samouczek zostanie usunięty i zastąpiony stroną dyskusji na temat dostępnych opcji zarządzania zależnościami.