Jaki jest związek między virtualenv i pyenv?

Niedawno nauczyłem się, jak używać virtualenv i virtualenvwrapper w moim przepływie pracy, ale widziałem o pyenv wspomnianym w kilku przewodnikach, ale nie mogę zrozumieć, czym jest pyenv i czym różni się / jest podobny do virtualenv. Czy pyenv jest lepszym / nowszym zamiennikiem virtualenv czy darmowym narzędziem? Jeśli to drugie, to co robi inaczej i jak te dwa elementy (i virtualenvwrapper, jeśli dotyczy) współpracują ze sobą?

Pyenv i virtualenv to bardzo różne narzędzia, które działają na różne sposoby, aby robić różne rzeczy:

• Pyenv jest rozszerzeniem bash - nie będzie działać w systemie Windows - które przechwytuje wywołania do języka Python, pip itp., Aby skierować je do jednego z kilku łańcuchów narzędzi systemu Python. Więc zawsze masz dostępne wszystkie biblioteki, które zainstalowałeś w wybranej wersji Pythona - jako takie jest dobre dla użytkowników, którzy muszą przełączać się między różnymi wersjami Pythona.

• VirtualEnv jest czystym Pythonem , więc działa wszędzie, tworzy kopię, opcjonalnie konkretną wersję, python i pip lokalną dla aktywowanego środowiska, które może zawierać linki do bieżącego łańcucha narzędzi systemu, jeśli nie, możesz zainstaluj tylko znany podzbiór bibliotek w tym środowisku. W związku z tym prawie na pewno jest znacznie lepszy do testowania i wdrażania, ponieważ dokładnie wiesz , które biblioteki, w jakich wersjach są używane, a globalna zmiana nie wpłynie na twój moduł.

venv python> 3.3

Zauważ, że od Pythona 3.3 i nowszych istnieje wbudowana implementacja VirtualEnv o nazwie venv (z, w niektórych instalacjach opakowaniem o nazwie pyvenv - ten wrapper jest przestarzały w Pythonie 3.6 ), który prawdopodobnie powinien być używany w pierwszej kolejności. Aby uniknąć możliwych problemów z opakowaniem, często dobrym pomysłem jest użycie go bezpośrednio przy użyciu /path/to/python3 -m venv desired/env/pathlub możesz użyć doskonałego pyselektora Pythona w oknach z py -3 -m venv desired/env/path. Utworzy katalog określony w desired/env/pathpliku configure i odpowiednio go zapełni. Ogólnie jest to bardzo podobne do używania VirtualEnv.

Dodatkowe narzędzia

Jest kilka narzędzi, o których warto wspomnieć i rozważyć, ponieważ mogą one pomóc przy użyciu jednego lub więcej z powyższych:

• VirtualEnvWrapper Zarządzaj i upraszczaj używanie i zarządzanie VirtualEnv - Cross Platform .
• pyenv-virtualenv , instalowany przez pyenv-installer , który zapewnia narzędzia PyEnv do zarządzania i łączenia się z VirtualEnv - dzięki temu możesz mieć podstawową instalację, która zawiera więcej niż jedną wersję Pythona i tworzyć izolowane środowiska w każdym z nich - Linux / OS- X . Zaproponowane przez Johanna Visagiego
• PyInstaller może pobrać twój kod Pythona, prawdopodobnie opracowany i przetestowany pod VirtualEnv, i połączyć go tak, aby mógł uruchomić jedną platformę, na której nie jest zainstalowana twoja wersja Pythona - Zwróć uwagę, że nie jest to kompilator krzyżowy, będziesz potrzebować systemu Windows (wirtualnego -) maszyna do budowania instalacji systemu Windows itp., ale może być przydatna nawet tam, gdzie można mieć pewność, że Python zostanie zainstalowany, ale nie można mieć pewności, że wersja Pythona i wszystkie biblioteki będą zgodne z Twoim kodem.

virtualenvpozwala na stworzenie własnej instalacji Pythona np. w podkatalogu Twojego projektu. W ten sposób każdy z twoich projektów może mieć swój własny python(lub nawet kilka) pod odpowiednim virtualenv. Dla niektórych / wszystkich virtualenvów jest w porządku, aby mieć nawet tę samą wersję python(np. 2.7.16) bez konfliktów - żyją osobno i nie znają się. Jeśli chcesz użyć któregokolwiek z tych pythonplików, musisz to activatezrobić (uruchamiając skrypt, który tymczasowo zmodyfikuje twój, PATHaby upewnić się, że bin/katalog virtualenv jest pierwszy). Od tego momentu wywołanie python(lub pipitp.) Będzie wywoływać wersję tego virtualenv, dopóki deactivatejej nie wyślesz (co przywraca PATH).

pyenvdziała na szerszą skalę niż virtualenv- przechowuje rejestr instalacji Pythona (i może być używany do instalowania nowych) i pozwala skonfigurować, która wersja Pythona ma zostać uruchomiona, gdy użyjesz pythonpolecenia. Brzmi podobnie, ale praktyczne zastosowanie jest nieco inne. Działa poprzez dołączenie swojego pythonskryptu podkładki do twojego PATH(na stałe), a następnie podjęcie decyzji, który „prawdziwy” ma pythonzostać wywołany. Możesz nawet skonfigurować pyenv, aby wywoływał jeden z twoich pythonów virtualenv (za pomocą pyenv-virtualenvwtyczki). Wersje Pythona, które instalujesz za pomocą, pyenvprzechodzą do jego $(pyenv root)/versions/katalogu (domyślnie katalog główny pyenv to ~ / .pyenv), więc są bardziej „globalne” niż virtualenv. Zwykle nie można powielać zainstalowanych wersji Pythona pyenv, przynajmniej nie jest to głównym pomysłem.

Aby utworzyć virtualenv z określoną wersją Pythona, musisz mieć tę wersję gdzieś w swoim systemie (niezależnie od tego, czy jest włączona, PATHczy nie) i zasadniczo sklonować ją do nowo utworzonego virtualenv. Oczywiście jednym ze sposobów uzyskania określonej wersji jest zainstalowanie jej za pośrednictwempyenv . Gdy to zrobisz, poszczególne virtualenvy mogą się dowolnie różnić, instalując w nich różne moduły (lub ich wersje).

W skrócie:

• virtualenv pozwala na tworzenie lokalnych, niezależnych instalacji Pythona poprzez klonowanie z już istniejących
• pyenv pozwala na jednoczesną instalację różnych wersji Pythona (w całym systemie lub tylko dla użytkownika lokalnego), a następnie wybranie, który z wielu Pythonów ma być uruchamiany w dowolnym momencie (w tym te utworzone przez virtualenv lub Anaconda)