>> 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 _______________________________________________ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python