[python] PYTHONPATH

[Petr Blahos]

>> Ale jasne,
>> Resit, jak to delaji jine unixove programy je sice zajimavy, ale cekal bych, ze na python ml se bude radit standardni reseni pythonu, ne miliony ostatnich.
> To je špatně na tolik způsobů že ani nevím kde začít...
>
> Za prvé, standartní pythoní způsob je PYTHONPATH (a .pth, ale to je spíš
> bokovka), to je zdokumentovaná součást interpretru. Virtualenv je zvlášt
> balený wrapper, který dokonce ani není ve standartní knihovně.

Mě mate, že tomu říkáš wrapper. Virtualenv nikde nic neobaluje. Virtualenv
nastaví prostředí, vpodstatě udělá PYTHONHOME="" PYTHONPATH="", a spustí
interpreter na jisté cestě, což implikuje hledání lib na určité cestě.
Tam se opět nic
ničím neobaluje, jenom se nastaví cesty, na kterých se hledají
knihovny. Podle mě
virtualenv můžeme nazýval lecjak, ale rozhodně ve mě neevokuje wrapper.

> Za druhé, nejsou žádné miliony ostatních, ale jen jeden způsob který
> používají miliony programů: cesty oddělené dvojtečkou v proměnné
> prostředí. Dokonce i Java se toho drží, a to už je tedy něco!
>
> Za třetí to celé má důvod, pokud "standardni reseni pythonu"  nebude
> totéž jako "jak to delaji jine unixove programy" tak máš zásadní

Bude podle Tebe vpořádku (myslím dostatečně unixové), když udělám
        PYTHONHOME=cesta_nekam python mujskript.py
? Protože tohle je jeden ze způsobů, jak virtualenv použít.

> problémy s interoperatibilitou. Představ si to naopak - když ty budeš
> potřebovat z pythonu spustit program v javě nebo ruby, je jednodušší
> sáhnout známým způsobem do prostředí nebo zkoumat jaký speciální nástroj
> si jeho autoři zase vymysleli? (nápověda: je to chyták)

Hmm, programy v javě, které jsem před lety potkával já (ant, tomcat,
...), k tomu
přistupovaly tak, že měly spouštěcí shell script, který nastavil JAVA_HOME,
k tomu ANT_HOME nebo tak něco, zpravidla si z ANT_HOME nebo tak něčeho
posbíral knihovny z lib/ext, vytvořil z nich parametr pro -classpath a
spustil javu
z JAVA_HOME. Když bych to dělal z programu a nechtěl spouštět ten skript,
tak bych tohle všechno musel řešit sám. Za domácí úkol si zkusím najít deb
balíček. Každopádně, nejjednodušší je spustit pomocí systémovýho shellu
skript, kterej má na první řádce napsaný, čím se má provést. Např. tím
interpreterem pythonu ve virtualenv.

Aha, když je to chyták, tak správná odpověď je: Je mi jedno, jaký spec. nástroj
si jeho autoři vymysleli, protože spouštím "program", ne "interpreter
s parametrem
jméno skriptu", a ten program se o obstarání toho spec. nástroje postará sám.

[...]
> soudů: IMO Python deployment je totéž jako Java deployment nebo PHP
> deployment - nesmysl.
Tady se asi něco ztratilo?

Totiž, aby vám nepřipadalo, že tady jenom zbytečně otravuju. Pokud si dobře
vzpomínám, v jakém duchu byla vedená celá tahle diskuze, a to v duchu správného
nastavování environment variables, tak nevidím rozdíl mezi tím, že
použiju virtualenv
(což vpodstatě jen nastaví, kde se hledají knihovny), a nepoužiju
virtualenv, jenom si
nastavím, kde se hledají knihovny. Nadruhou stranu, to, jak se tady
objevilo nastavit
PYTHONPATH systemwide, a ještě k tomu na svoje moduly, mi přijde jako mnohem
větší prasárna, než všechny virtualenvy dohromady.

Kde rozdíl vidím je:
Pro balíčkovací systém:
+ snadná aktualizace všech balíčků
+ bude to fungovat, ikdyž se zaktualizuje python
Pro virtualenv:
+ možnost mít různá prostředí s různými verzemi či sadami knihoven -
umíte to balíčkovacím systémem?
+ možnost použití v OS, kde není balíčkovací systém
+ vlastní balíčkovací systém (pip nebo easy_install) pro případ, že
zrovna pro knihovnu, kterou potřebuju, není rpm/deb

--
Petr