Modul „venv“

Python Jiří Znamenáček Modul „venv“ 2014-11-10

Tato přednáška pojednává o použití modulu venv pro tvorbu a správu virtuálních prostředí od Python'u 3.3 výše.

Pro obecný úvod do virtuálních prostředí a jejich technické realizace si prostudejte nejdříve příslušnou přednášku.

Od Python'u verze 3.8 se virtuální prostředí zavádí již jen jediným způsobem přímo pomocí odpovídajícího modulu venv:

python -m venv /cesta/k/novému/virtuálnímu/prostředí

Uvedený příkaz vyrobí cílový adresář a v něm:

konfigurační soubor pyvenv.cfg s klíčem home ukazujícím na příslušnou pythoní binárku (a s případnými dalšími klíči podle konkrétní podoby zavolání), kterou zasymlinkuje/zkopíruje do podadresáře bin (Scripts pod Windows);
podadresář lib/pythonX.Y/site-packages (Lib\site-packages pod Windows);
prázdný podadresář Include;
od verze Python'u 3.13 též soubor .gitignore, který vyjme adresář virtuálního prostředí z verzování gitu.

Vytvoření virtuálního prostředí je možné ovlivnit několika přepínači:

--system-site-packages – knihovny z globálního adresáře site-packages budou přístupné (ale místní stejného jména budou pořád mít prioritu); Tato volba se projeví nastavením klíče include-system-site-packages v konfiguračním souboru virtuálního prostředí pyvenv.cfg na hodnotu True.
--symlinks – pokusí se přednostně odkazy na potřebné soubory vyrobit jako symbolické odkazy; Na Windows je sice možné simlinky také vytvořit, ale není to dobrý nápad, protože např. dvojtý klik na python.exe v Prohlížeči je bude ve výsledku ignorovat.
--copies – pokusí se přednostně odkazy na potřebné soubory vyrobit jako kopie (od Python'u 3.4);
--clear – již existující adresář virtuálního prostředí stejného jména nejdříve smaže;
--upgrade – povýší virtuální prostředí na novou verzi Python'u;
--without-pip – do virtuálního prostředí nebude nainstalován pip (který tam totiž jinak od Python'u 3.4 je ve výchozím nastavení přítomen);
--prompt VÝZVA – alternativní prefix virtuálního prostředí na příkazové řádce (jinak se použije jméno vytvářeného adresáře);
--upgrade-deps – v podstatě v rámci instalace povýší nainstalovaný pip rovnou na nejnovější verzi;
--without-scm-ignore-files – nevyrobí konfigurační soubor pro ignorované soubory v rámci DVCS (toho času tedy jenom .gitignore).

PS: Modulu venv je srdečně jedno, v jakém pořadí zapíšete parametry a cestu k virtuálnímu prostředí.

Budete-li inteprepret Python'u a jiné programy/skripty z virtuálního prostředí spouštět pouze pomocí zde umístěných odkazů/souborů (tedy s uvedením cesty k nim), nemusíte nic jiného dělat – jak vámi napsané pythoní skripty, tak třeba i instalace balíčků do místního site-packages budou probíhat pouze zde.

Nechcete-li však myslet na cesty ke spustitelným souborům, můžete dané virtuální prostředí tzv. aktivovat, čímž vlastně jen přidáte odkaz na podadresář bin (Scripts pod Windows) daného virtuálního prostředí na začátek cesty. (Až ho nebudete potřebovat, nezapomeňte ho zase deaktivovat!)

(De)aktivace se provádí pomocí skriptu activate/deactivate, jehož umístění i celý název je platformně závislé. Dvě nejčastější varianty (z pěti podporovaných):

# Linux s bashem $ source <venv>/bin/activate # Windows s cmd C:> <venv>/Scripts/activate.bat <venv> zde zastupuje adresář, v němž je „nainstalováno“ příslušné virtuální prostředí. Aktivace je platná pouze pro aktuální shell (konzoli), takže deaktivaci můžete provést také jeho pouhým zavřením. Pro aktivaci v PowerShellu pravděpodobně budete muset aktivovat oprávnění PS C:\> Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser .

Z praktických důvodů je doporučováno zavést virtuální prostředí přímo v adresáři projektu, kde ho potřebujete. A aby se tam nepletlo, doporučovaný název je pak .venv, tedy s tečkou na začátku.

Tím ho i vizuálně dostáváte na úroveň adresářů typu .git a jiných konfiguračních.

Virtuální prostředí by nemělo být součástí verzování projektu, pouze soubor pro jeho snadné znovuvytvoření v případě potřeby (viz requirements.txt). Proto je také ve výchozím nastavení automaticky vyroben odpovídající .gitignore.

Což je pochopitelné, když si uvědomíte, jak obrovské mohou být knihovny požadované projektem. Třeba takový JupyterLab to hravě dotáhne na stovku závislostí a několik set megabajtů zabraného místa.

Při práci s více prostředími zase není až takový problém se ztratit. Naštěstí pro nás obsahuje modul sys několik atributů hlásících adresář umístění aktuálně spuštěného Python'u, které nám pomohou:

sys.base_prefix – adresář instalace, nemění se ve virtuálním prostředí;
sys.prefix – adresář aktuálně spuštěné binárky, mění se podle virtuálního prostředí.

Tudíž se často stačí podívat do atributu sys.prefix, abychom se zorientovali.

Naneštěstí je atribut sys.prefix přenastaven na odpovídající aktuální hodnotu modulem site, takže podaří-li se vám pustit Python bez něj (což je sice velmi neobvyklé, ale jde to), máte stejně smůlu.

Virtuální prostředí se zruší prostým smazáním příslušného adresáře. (Takže v případě doporučeného použití „virtuální prostředí jako podadresář .venv projektu“ prostě smažete odpovídající adresář .venv.)

V rámci daného otevřeného shellu (pracovní konzole) ovšem zůstává aktivováno, proto ho nezapomeňte deaktivovat, jinak vám zůstanou v proměnných prostředí viset neplatné hodnoty! Nebo příslušný shell zavřete a otevřete si nový, tím se deaktivace provede automaticky.

Totéž se týká přechodu práce na jiný projekt v jiném virtuálním prostředí – ve stejném shellu nejdříve deaktivujte prostředí aktuální a následně aktivujte nové anebo daný shell zavřete a otevřete si nový, v němž aktivujete nové virtuální prostředí.