systemd2rc: Generování initskriptů ze systemd (diskuse)

[Josef Kufner]

Je to docela nezvyk, vidět vše nahňácané v jednom souboru.

Jak velkou podmnožinu systemd to zvládne?

[pavlix]

Je to docela nezvyk, vidět vše nahňácané v jednom souboru.

Ono to tak asi nezůstane, ten soubor nejspíše rozdělím ve chvíli, kdy se ukáže, že je důvod používat funkcionalitu nejen ve formě skriptu, ale i ve formě knihovny.

Jak velkou podmnožinu systemd to zvládne?

Je to work in progress, takže takovou, jaká se naimplementuje, v tomto ohledu se chystám přistupovat k RFE jako k bugreportům, takže dopíšu, co komu bude chybět. Spouštění simple a oneshot služeb je implementovatelné bez problémů včetně všech těch hovadin okolo. Forking jde řešit specifikací pidfile vytvářeného službou (současný stav) nebo možná i nějakým wrapperem. Zatím jsem neřešil notify.

Problém je se závislostmi a pořadím, které typicky nejdou přímočaře přeložit, takže očekávám, že je bude muset volající často specifikovat na příkazové řádce, což ještě není implementováno. Zajímá tě ještě něco konkrétního?

[Stevko]

Keď som videl, čo všetko by mal systemd zvládnuť, tak som zvedavý.

[pavlix]

Cílem projektu je, aby package maintainer nemusel vypisovat celý initskript, pokud se dá alespoň částečně automaticky generovat. V tomto kontextu je pokrývání funkcionality systemd úplně mimo. Pokud nějaký systém bude 100% pokrývat funkcionalitu systemd, tak bych spíše doporučoval, aby ten systém uměl číst systemd unity přímo. Tak to dělá i systemd s initskripty, a to nejsou zdaleka kompatibilní systémy. Smysl generování initskriptů je podle mě v tom, vytřískat z informací pro nekompatibilní systém maximum a zbytek případně nechat specifikovat na příkazové řádce.

[Josef Kufner]

Co udělá systemd, když narazí na neznámou volbu? Třeba by se chybějící volby daly připisovat přímo do systemd konfiguráku. Tedy pokud takové volby jsou vůbec potřeba.

[pavlix]

Nezkoušel jsem, co dělá systemd s neznámou volbou. Ale spíš vidím smysl ve využití nezměněných systemd unit z upstreamu a doplnění nějakých těch detailů v argumentech.

[Josef Kufner]

Hm, asi bych přidal pár speciálních komentářů (u těch je jistota, že to nerozbijou) a poslal to upstreamu.

[pavlix]

Osobně mi to moc nedává smysl, ale různým vylepšením se nebráním, pokud by to někdo tak chtěl používat.

[JS1]

Je to docela nezvyk, vidět vše nahňácané v jednom souboru.

Mne naopak prijde v dnesni dobe nelogicky opak. Puvodne vzniklo rozdelovani programu na souboru kvuli modularite (absenci verzovani) a omezeni kompilatoru (ktere mohly zpracovat najednou jen maly soubor). Ale striktne vzato to neni potreba.

[pavlix]

Tak já jsem většinou spíš modulární, odděluju programy do celků, které se běžně samostatně upravují, ale systemd2rc se prozatím vždy upravuje jako celek, žádná část nemá ani relativně stabilní API, statická data jako LSB_HEADER se sdílejí, atd...

[JS1]

Tak to co jsem napsal je trochu provokativni, protoze vim, ze Franta ma rad Javu.

Nejsem obhajce toho mit vsechno v jednom souboru (i kdyz u konverzniho skriptu se to hodi, ze se nemusi slozite instalovat), ale javovsky zpusob deleni mi pripada sileny. Jsem zastance toho, ze dobry program by mel byt citelny tak trochu jako knizka, tedy od obalky k obalce (mozna s vynechanim nekterych casti).

Nicmene zatim jsem neslysel dobre zduvodneni, proc to delat jak se to dela v Jave. Takze kdyz uz ti to vytyka, at prinese nejaky zajimavy argument!

[pavlix]

Tak to co jsem napsal je trochu provokativni, protoze vim, ze Franta ma rad Javu.

A Pepa má taky rád javu?

i kdyz u konverzniho skriptu se to hodi, ze se nemusi slozite instalovat

Tak já už mám přidaný setup.py a je fakt, že Python je v tomhle vcelku flexibilní a hledá jak v aktuálním adresáři, tak v systémovém, takže rozdělení nepřinese zásadní komplikace.

[JS1]

Ah, mea culpa Myslel jsem, ze to napsal Franta.. No nevadi, odpovedet muze taky.

[pavlix]

Mně se jenom líbilo, že jsi zaměnil dva lidi s takovými blízkými jmény :).

[kralyk z abclinuxu]

Nejsem obhajce toho mit vsechno v jednom souboru (i kdyz u konverzniho skriptu se to hodi, ze se nemusi slozite instalovat), ale javovsky zpusob deleni mi pripada sileny. Jsem zastance toho, ze dobry program by mel byt citelny tak trochu jako knizka, tedy od obalky k obalce (mozna s vynechanim nekterych casti).

Tak já si tu tradičně přihřeju polívku s Rustem - viz Crates and Modules. Hlavně ty moduly se mi docela líbí...

[pavlix]

Jestliže se tam píše, že závislosti mezi crates tvoří strom, znamená to, že nemůžu vytvořit dva moduly, které jsou na sobě závislé navzájem? Je vcelku běžné, že dva céčkové soubory přímo využívají funkce ze sebe navzájem, ať už sdílí jeden hlavičkový soubor nebo se překřižují, tak mě zajímalo, jestli je ta možnost, případně jak se to vůbec řeší s typováním, když na sobě závisí datové modely apod.

[kralyk z abclinuxu]

IMHO tím stromem se myslí pouze hierarchie modulů (analogie adresářové struktury, tj. acyklická záležitost), to, že jednotlivé zdrojáky na sebe navzájem mohou odkazovat (use) cyklicky, s tím v zásadě nesouvisí. Moduly jsou pouze k tomu, aby sis mohl 1) zdrojáky rozstrkat do hierarchie a 2) řídit viditelnost (ta se v Rustu řeší pouze právě mezi moduly).

Jestli mohou být cyklické závislosti i mezi crates, to už nevim přesně, ale jsem si skoro jistý, že ne.

[pavlix]

Tak teď mám pocit, že jsi mi odpověděl jak že lze na sebe odkazovat cyklicky, tak že to nelze. Nezapomeň, že je to pro mě (a nejen pro mě) úplně cizí jazyk.

[kralyk z abclinuxu]

Lze to, ale nijak to nesouvisí s tím, že moduly tvoří strom. Je to jako když si v céčkovém projektu rozstrkáš zdrojáky do různých složek - máš strom zdrojáků, ale ten nutně nemusí vůbec souviset se stromem závislostí v kódu.

V Rustu ve zdrojácích ani nikde nejsou explicitně specifikovány závislosti mezi moduly/soubory. Závislosti mezi moduly vzniknou tím, že se prostě na nějakém místě v kódu použije symbol z nějakého jiného modulu v rámci jednoho crate. Celý crate se překládá najednou, kompilátor si závislosti mezi moduly - ať už cyklické nebo ne - pořeší.

Crate je pak celá binárka (program nebo knihovna), takže tam už cyklické závislosti afaik nemůžou bejt.

[pavlix]

V Rustu ve zdrojácích ani nikde nejsou explicitně specifikovány závislosti mezi moduly/soubory.

Já jsem to chápal tak, že crate je soubor a modul se vytváří explicitně, takže ve skutečnosti jsou crate, soubor a modul tři různé pojmy. To potom znamená, že Rust neumí postupnou kompilaci jako céčko, že.

Crate je pak celá binárka (program nebo knihovna), takže tam už cyklické závislosti afaik nemůžou bejt.

Zajímavé.

[kralyk z abclinuxu]

takže ve skutečnosti jsou crate, soubor a modul tři různé pojmy

Přesně tak. V praxi samozřejmě mít co soubor, to modul, nicméně u větších modulů bude mít smysl je roztáhnout do více souborů...

To potom znamená, že Rust neumí postupnou kompilaci jako céčko, že.

To, co jsem popsal, je výchozí chování, kdy ti rustí kompilátor v podstatě poskytne jednoduchý build systém. Jinak má hafo konfigurace, může generovat všechno možné od celých binárek přes jednotlivé .o soubory až po asm nebo ir, takže afaik by to mělo jít použít v nějakém build systému á la C. Koneckonců backendem je LLVM.

[pavlix]

Popravdě dosud považuju kombinaci make, shellu a autotools za nepřekonanou a rychlost kompilace za naprosto zásadní, jenže jestli to dobře chápu, nemá Rust hlavičkové soubory a tudíž je potřeba při kompilaci vždy parsovat všechny závislosti, aby měl kompilátor k dispozici informace o datových strukturách. Rovněž mi tak chybí rozumné oddělení API, ABI a implementace, které tedy bohužel není zrovna dokonalé ani v C, ale za ty roky (a desetiletí) už jsou zavedené techniky, jak tyto věci vcelku jasně oddělit. Tady asi ani tak nehraje roli LLVM backend, ale ten frontend jako takový.

[kralyk z abclinuxu]

Popravdě dosud považuju kombinaci make, shellu a autotools za nepřekonanou a rychlost kompilace za naprosto zásadní

Popravdě považuju autotools za dílo ďáblovo

jenže jestli to dobře chápu, nemá Rust hlavičkové soubory a tudíž je potřeba při kompilaci vždy parsovat všechny závislosti, aby měl kompilátor k dispozici informace o datových strukturách.

To ano, ale vzhledem k tomu, že ten kompilátor je beztak pomalej a žere dost paměti, je to asi celkem detail

Rovněž mi tak chybí rozumné oddělení API, ABI a implementace

Tomu moc nerozumim... Ale celkově mi přijde, že se diskuse posunula do roviny "Rust není C", s čímž se nedá než souhlasit...

[pavlix]

Popravdě považuju autotools za dílo ďáblovo

Já za velmi podařené dílo ďáblovo, které není ani v nejmenším, čím nahradit.

To ano, ale vzhledem k tomu, že ten kompilátor je beztak pomalej a žere dost paměti, je to asi celkem detail

Právě naopak, jestliže kompilátor nesází výsledky bleskově, hodí se postupná kompilace jako sůl. Navíc někteří z nás používají ccache, takže umíme využít výsledků kompilace opakovaně i při formálních změnách nebo naopak při kompilaci z čistých zdrojů, což vývojář potřebuje dost často. Na Gentoo navíc výsledek takto optimalizované kompilace můžeš dostat rovnou do systému.

Tomu moc nerozumim... Ale celkově mi přijde, že se diskuse posunula do roviny "Rust není C", s čímž se nedá než souhlasit...

Uznávám, že C je na Linuxu co do toolingu a zvyklostí natolik kvalitní ekosystém, že je těžké se mu i kdyby jen přiblížit. Na druhou stranu jsem slyšel Rust prezentovaný jako jazyk pro systémové programování, což v kontextu, kde se pohybuju zastává C, maximálně ještě prokládané Pythonem, který se ovšem prakticky za všech okolností používá právě jako nadstavba nad C.

Můžeš mi tedy říct, do jaké oblasti je Rust vhodný, když to podle tebe není ta, kde se používá C?

[kralyk z abclinuxu]

Já za velmi podařené dílo ďáblovo, které není ani v nejmenším, čím nahradit.

CMake, jednoznačně. Ale i některé jiné systémy považuju za furt lepší než autotools...

Právě naopak, jestliže kompilátor nesází výsledky bleskově, hodí se postupná kompilace jako sůl. Navíc někteří z nás používají ccache, takže umíme využít výsledků kompilace opakovaně i při formálních změnách nebo naopak při kompilaci z čistých zdrojů, což vývojář potřebuje dost často.

Nevim přesně, co myslíš tou "postupnou kompilací", každopádně použitelný build systém by imho měl umět ccache-like funkcionalitu bez externí berličky. Build systém v rustc (Rust compiler) v základu takovouhle funkcionalitu nemá, je jen jednoduchý.

Jinak rustc jako takový používá pro sestavování autotools (z čehož nejsem moc nadšen a taky to buhvíjak dobře nefunguje) a je možné použít ccache, ale jak to přesně mají pořešeno, to nevím. rustc umí na žádost vyplivnout dependency info, takže možná že to je tam použito. Osobně se těším na něco rozumnějšího, např. podpora rustu v CMake by byla fajn (někde na githubu jsem viděl takové pokusy, uvidíme, co z toho bude...).

Můžeš mi tedy říct, do jaké oblasti je Rust vhodný, když to podle tebe není ta, kde se používá C?

To jsem neřekl, určitě to je ta, kde se používá C/C++ (víceméně), akorát nemá moc cenu se na něj snažit napasovat věci specifické pro C, jako třeba header files.

[pavlix]

CMake, jednoznačně.

Zkoušel jsem a jednoznačně ne. Je to sice zajímavá alternativa, ale i když odhlédnu od toho, že je v mnoha ohledech zcela zbytečně nekompatibilní, plnohodnotná náhrada to rozhodně není. Ale pokud budeš chtít zdůvodnění, tak to je na delší povídání. S autotools jsem natolik sžitý, že mnohou funkcionalitu používám

Nevim přesně, co myslíš tou "postupnou kompilací", každopádně použitelný build systém by imho měl umět ccache-like funkcionalitu bez externí berličky.

To není berlička, ale nástroj, a navíc má mnohem blíž ke kompilátoru než k build systému. Nejjednodušší způsob, jak může build systém něco takového podporovat je právě použít kompilátor přes ccache wrapper.

Jinak rustc jako takový používá pro sestavování autotools (z čehož nejsem moc nadšen a taky to buhvíjak dobře nefunguje)

Což ovšem asi nebude chyba autotools, že. Autotools rozhodně mají své rezervy, na které narážím celkem často, a za build systém, který by byl plnohodnotnou náhradou autotools, byl by srozumitelnější, a ještě by řešil ty věci, na které jsem narazil, bych velice ocenil.

a je možné použít ccache, ale jak to přesně mají pořešeno, to nevím

Jsou dva základní způsoby, jak použít ccache s autotools. Jeden je ./configure CC="ccache gcc", druhý je PATH=$PATH:/usr/lib64/ccache/bin.

To jsem neřekl, určitě to je ta, kde se používá C/C++ (víceméně), akorát nemá moc cenu se na něj snažit napasovat věci specifické pro C, jako třeba header files.

Já jsem zase neřekl, že se na něj mají napasovat header files, ale ptal jsem se jak se tam řeší ty věci, které se v C řeší přes header files. Shodit můj dotaz s odkazem, že mi na Rustu vadí, že není C, je dost laciné, vzhledem k tomu, že jsem nic takového ani nenaznačil. Jen na C kromě vlastností samotného jazyka oceňuj to, že kolem něj je tolik nástrojů, zkušeností a best practices, že nenarážíš na nové problémy, které ještě nikomu nestály za řešení. To, že se u Rustu nemám koho zeptat na základní otázky, abych dostal smysluplnou odpověď, tuto výhodu C jenom podtrhuje.

[kralyk z abclinuxu]

Nejjednodušší způsob, jak může build systém něco takového podporovat je právě použít kompilátor přes ccache wrapper.

Pro build systém to určitě jednodušší je, uživatel toho build systému musí nainstalovat si a pochopit další nástroj...

Já jsem zase neřekl, že se na něj mají napasovat header files, ale ptal jsem se jak se tam řeší ty věci, které se v C řeší přes header files.

Což je konkrétně co?

Jen na C kromě vlastností samotného jazyka oceňuj to, že kolem něj je tolik nástrojů, zkušeností a best practices, že nenarážíš na nové problémy, které ještě nikomu nestály za řešení. To, že se u Rustu nemám koho zeptat na základní otázky, abych dostal smysluplnou odpověď, tuto výhodu C jenom podtrhuje.

Tak na to se celkem nedá moc říct, těch >40 let se jentak nedožene... Nicméně ironie je, že na začátku jsme se bavili o modulech, což je oblast, ve které C nenabízí vůbec nic...

[pavlix]

Pro build systém to určitě jednodušší je, uživatel toho build systému musí nainstalovat si a pochopit další nástroj...

No jeje, tak si vývojář nainstaluje jeden balíček a pokud se nenastaví na cestu sám, tak to udělá.

Což je konkrétně co?

A to se mi zase teď vysvětlovat nechce, je to základní znalost stávajícího ekosystému, to se radši časem zeptám někoho, kdo trochu tuší.

Tak na to se celkem nedá moc říct, těch >40 let se jentak nedožene... Nicméně ironie je, že na začátku jsme se bavili o modulech, což je oblast, ve které C nenabízí vůbec nic...

A to je tak špatné chtít po novém nástroji, aby kromě nových vlastností zastával dobře i to, co se starým už umíme (a to není jen o nástroji, ale i o dostupnosti informací)? Na céčku je samozřejmě spousta věcí na hovno a člověk by tak rád ocenil alternativu, které je řeší. Ale u programovacího jazyka je to ještě horší než u těch autotools. Jejich vlastnosti člověk vždycky nějak naskriptuje, když má na takové věci dost času, ale základní věci prostě rozumně jako uživatel nenahradíš.

[kralyk z abclinuxu]

A to se mi zase teď vysvětlovat nechce, je to základní znalost stávajícího ekosystému, to se radši časem zeptám někoho, kdo trochu tuší.

Neboj, vím co jsou headery, spíš mě zajímalo, v čem vidíš takovej přínos. Imho jsou spíš důsledkem způsobu, jak se C/C++ kompiluje (viz třeba nutnost psát include guards). Mít skupinu funkcí, struktury nebo třídy (když jde o C++) přehledně definované v headeru odděleně od implementace je celkem fajn, to zcela uznávám, nicméně stejně musí člověk používat všelijaké triky, aby implementaci skutečně důsledně oddělil, tj. různé opaque pointery ve strukturách, PIMPL v C++ a některé věci ani oddělit z headerů nemůžeš, např. generika implementovaná preprocesorovou magií v C a templaty v C++ ...

A to je tak špatné chtít po novém nástroji, aby kromě nových vlastností zastával dobře i to, co se starým už umíme (a to není jen o nástroji, ale i o dostupnosti informací)?

V zásadě ne, podle toho, co po tom nástroji vlastně chceš. Zatím jsme zaznamenal požadavek na možnost použití ccache, který s použitím vestavěného build systému splněn není, s použitím externího (autotools) ano.

[pavlix]

Neboj, vím co jsou headery, spíš mě zajímalo, v čem vidíš takovej přínos

Aha. Ty totiž stále ještě předpokládáš, že požaduju po Rustu, aby fungoval v ohledu struktury zdrojáků jako C, ale to je nesmysl. Když se začal trochu víc propagovat Git jako náhrada Subversion, tak si člověk na každém rohu mohl přečíst, jak dělat věci, které dělal se stávajícím systémem, které věci nejdou, proč nejdou, a co s tím. Pokud mám vůbec chápat Rust jako možnou náhradu C, tak k tomu potřebuju mít v ruce něco podobného.

nicméně stejně musí člověk používat všelijaké triky, aby implementaci skutečně důsledně oddělil

Nejpraktičtější je chápat céčko jako nadstavbu nad assemblerem a bez dalších nástrojů (ať už knihoven nebo různých generátorů) od něj neočekávat zázraky. Na druhou stranu je údržba ABI v čistém C strašně jednoduchá díky tomu, že ten jazyk dělá v podstatě jenom to, co se mu řekne. Exportovat pointer na nedefinovanou strukturu a poskytnout k němu sadu funkcí je tak easy jak si to jenom umím představit :).

V zásadě ne, podle toho, co po tom nástroji vlastně chceš.

Zatím si chci pouze udělat představu, co umí a k čemu je vhodný.

Zatím jsme zaznamenal požadavek na možnost použití ccache

To je nesmysl. Jediný požadavek, který by s tím mohl souviset je rychlá kompilace, přičemž rád slevím z nároků u první kompilace daného projektu, ale rád bych, aby byla rychlá alespoň každá další kompilace, a to i v případě, že udělám změnu. To se v C zajišťuje především pomocí oddělené kompilace za použití hlavičkových souborů a někdy se hodí to spojit s ccache. Použít ccache je ale prostředek, nikoliv cíl, a pokud se ten prostředek použije špatně (například se cachuje po příliš velkých jednotkách), tak nemusí k naplnění cíle vůbec dojít.

s použitím vestavěného build systému

Popravdě řečeno jako céčkař nevidím důvod, aby měl kompilátor jazyka vestavěný build systém.

[kralyk z abclinuxu]

Pokud mám vůbec chápat Rust jako možnou náhradu C, tak k tomu potřebuju mít v ruce něco podobného.

Úrovní abstrakce je Rust mnohem blíž k C++, D apod. než k C.

Jinak nějaké takové informace existují, zejména co se jazyka jako takového týče. Viděl jsem různé tutoriály typu "Rust for C++ programmers", "Rust for Rubyists" (nevim, proč zrovna Ruby, které má úplně jiné zaměření, ale w/e) a podobně. Informací týkajících se build systémů, toolingu a vůbec ekosystému okolo je zatím spíš míň a rychle zastarávají, což je dané hlavně tím, že tyhle věci teprve vznikají, takže bych je čekal spíš až s vydáním stabilní* verze jazyka a kompilátoru. Nicméně na ML a IRC jsou i teď obvkle ochotni vysvětlit/poradit.

*) stabilní ve smyslu že nepadá už je, mám na mysli stabilní ve smyslu zachovávající kompatibilitu (ABI, jazyka, atd.)

Na druhou stranu je údržba ABI v čistém C strašně jednoduchá díky tomu, že ten jazyk dělá v podstatě jenom to, co se mu řekne. Exportovat pointer na nedefinovanou strukturu a poskytnout k němu sadu funkcí je tak easy jak si to jenom umím představit :)

To je zásluha unixového ekosystému a taky téměř univerzálního rozšíření GCC nebo kompatibilních kompilátorů, rozhodně ne jazyka C, který pro ABI prakticky nehne prstem. Určitě to je fajn, to souhlas, ale jinak moc nevim, proč to píšeš

Jediný požadavek, který by s tím mohl souviset je rychlá kompilace, přičemž rád slevím z nároků u první kompilace daného projektu, ale rád bych, aby byla rychlá alespoň každá další kompilace, a to i v případě, že udělám změnu.

Aha, hmm, tak na to aktuálně odpovím dost těžko, protože to závisí na X věcech (ja je kód rozdělen, jak/čim ho sestavuješ,...) a za chvíli se situace stejně změní. Jediný, co můžu říct celkem s jistotou, je, že výchozí build většího crate pomocí rustc je v současné době relativně pomalý a žere relativně dost RAM.

Popravdě řečeno jako céčkař nevidím důvod, aby měl kompilátor jazyka vestavěný build systém.

Já taky moc ne, ale někdy se to hodí, když potřebuješ rychle něco zkusit...

[pavlix]

Úrovní abstrakce je Rust mnohem blíž k C++, D apod. než k C.

To může být i fajn v závislosti na tom, jak je to celé postavené. Já jsem si třeba kdysi myslel, jak je C++ super, než jsem narazil na hromadu drobností, které si radši v C udělám jinak. Třeba v Pythonu se mi zdaleka tolik nestává, že bych narážel na to, že mi ten jazyk překáží, i když má taky své nevýhody třeba i oproti tomu C a teď nemám namysli neefektivní běh programů ve VM, kde je vše v hashovacích tabulkách.

To je zásluha unixového ekosystému a taky téměř univerzálního rozšíření GCC nebo kompatibilních kompilátorů, rozhodně ne jazyka C

To, že je to jednoduché je právě vlastností programovacího jazyka C. Proto to taky píšu. To, že je kolem toho tooling, je samozřejmě dobře, ale o tom až tak nemluvím.

Aha, hmm, tak na to aktuálně odpovím dost těžko, protože to závisí na X věcech (ja je kód rozdělen, jak/čim ho sestavuješ,...)

Tak třeba v C ho můžu rozdělit, jak uznám za vhodné a sestavuje se tak, že největší zpomalené způsobí změna hlavičkového souboru, který se používá ve velké části projektu. zase na druhou stranu není potřeba vícekrát zpracovávat celý zdroják, který za tím hlavičkovým souborem leží a který je násobně větší. Ke kompilaci přichází v ůvahu GCC nebo LLVM, přičemž co vím, tak LLVM má být podstatně rychlejší, ale ještě jsem se nedostal k tomu ho trochu víc používat.

Tady se už skutečně nebavíme ani tak o jazyce jako o existujících nástrojích a jejich dalším směřování. Ono totiž asi není problém vzít zdroják, který popisuje jak API, tak ABI, tak implementaci, a první dvě z nich vygenerovat a uložit jakožto (třeba i binární) obdobu hlavičkového souboru pro další zpracování. Nebo použít nějakou úplně jinou techniku, která mě třeba ani nenapadne.

[Zinger]

pavlix < Surý

[odin]

+1

[patrick]

pavlix << Surý

[kralyk z abclinuxu]

pavlix << "Hello world!" << endl;

[LLeoš]

jakoze pavlix je odpadni proud? souhlasim

[pavlix]

Jinak díky za tučňáka.

[lqw]

Slysel autor o funkci os.path.basename ? Nebo modulu argparse ? Doporucuju nahlednout do dokumentace ke standardni knihovne, at se zase nevymysli kolo

Pokud se uvazuje do budoucna o jakesi serioznosti, bylo by asi vhodne nasadit nektery z dostupnych parseru. Uvedene manualni parsovani ktere nepocita s nestandardnimi situacemi(format, znakova sada) a rozsiritelnosti, neni dostatecne.

Dal mi neni jasne proc je to napsane pro porad min rozsireny Python 3. Pouziti subgeneratoru tu je spis jako manyra nez nutnost. Jiny duvod ?

Btw. je po necem takovem vubec poptavka v Gentoo komunite ? Zatim jsem nezaznamenal ze by upstream zesilel a vetsina uz dodavala systemd unity.

[pavlix]

Slysel autor o funkci os.path.basename?

Patches welcome.

Nebo modulu argparse?

Slyšel a nevidí důvod ho použít. Na jednoduché věci je zbytečný, na středně složité ho autor čas od času použije a na cokoli komplikovanějšího je úplně na hovno. Autor čas od času uvažuje, že si napíše vlastní parser na parametry příkazové řádky, který bude trochu lépe ovladatelný. Navíc je tu možnost, že bude program portován na nějakou ze starších verzí Pythonu.

Uvedene manualni parsovani ktere nepocita s nestandardnimi situacemi(format, znakova sada) a rozsiritelnosti, neni dostatecne.

Konkrétně?

Dal mi neni jasne proc je to napsane pro porad min rozsireny Python 3.

Python 3 považuju za skvělý jazyk na psaní prototypů podobných věcí, jakmile budu rámcově spokojený s funkcionalitou, nevidím problém to portovat na Python ≥ 2.6, ve chvíli, kdy se ukáže, že je k tomu důvod.

Btw. je po necem takovem vubec poptavka v Gentoo komunite?

Vím minimálně o jednom člověku z Gentoo komunity, který to chce využívat, a to jsem já. Vivat open source!

Zatim jsem nezaznamenal ze by upstream zesilel a vetsina uz dodavala systemd unity.

Považuju naopak za velice rozumné, když tak upstream učiní a do několika projektů už jsem je sám poslal a byly přijaty. Je to nejen krok k lepší podpoře systemd, kdy maintaineři distribuce můžou odškrtnout další položku jako vyřešenou upstreamem, ale i ukázka, jak se má služba používat. To ve výsledku slouží nejen jako příklad lidem, ale lze z toho při troše snahy generovat hotové skripty, jako to dělám já. Jako maintainer balíků pro více než jednu distribuci to dokážu ocenit.

[jas]

Slyšel a nevidí důvod ho použít. Na jednoduché věci je zbytečný, na středně složité ho autor čas od času použije a na cokoli komplikovanějšího je úplně na hovno. Autor čas od času uvažuje, že si napíše vlastní parser na parametry příkazové řádky, který bude trochu lépe ovladatelný. Navíc je tu možnost, že bude program portován na nějakou ze starších verzí Pythonu.

Nejaky priklad, co take zasadne tam chyba? Samozrejme nejde spravit uplne vsetko, ale to vidim skor ako vyhodu -- vyzaduje si to isty navrh UI a je tam ista konzistencia medzi tym ako vyzera vstup python scriptov, co pouzivaju argparse.

btw: Pre starsi python (2.3+) je argparse dostupny vo forme externej kniznice.

[pavlix]

Nejaky priklad, co take zasadne tam chyba?

Je to takové celkově neovladatelné. Přijde mi, že od toho nemůžeš chtít nic víc než chtěl autor. Vyžaduje to primitivní návrh UI, což vyhovuje u běžných příkazů, která max implementují nějakou tu volbu. Zrovna na nástroj typu systemd2rc by to stačilo. Ale tuším, že jsem měl problém tam implementovat i něco, co by fungovalo aspoň trochu ve stylu iproute2 nebo git.

btw: Pre starsi python (2.3+) je argparse dostupny vo forme externej kniznice.

Externí závislosti bych zrovna v případě systemd2rc rád omezil na minimum, ale dobrá poznámka.

[Josef Kufner]

Velice pěkný je docopt, který byl přepsán i pro PHP. Nástroje ve stylu Gitu to umí. Programátor napíše nápovědu a ono ji to rozparsuje a použije ke zpracování parametrů na příkazové řádce.

[pavlix]

Díky, někdy zkusím a napíšu, jak mi to sedlo.

[Jakub Lucký]

Nebo použít Click od Armina Roachera. S tím jsem si hrál a přišlo mi to zcela geniální

[Josef Kufner]

Docopt má výhodu v tom, že byl přepsán pro PHP, neboť Python nepoužívám A havně se mi líbí, že napíšeš dokumentaci a už není třeba psát implementaci takto zdokumentovaného API.

[pavlix]

s/implementaci/boilerplate/

[Jakub Lucký]

Tomu říkám výhoda...

No, ono by to z toho Clicku asi šlo taky generovat, ani nevím, možná to umí...

[Bystroushaak]

Velice pěkný je docopt, který byl přepsán i pro PHP. Nástroje ve stylu Gitu to umí. Programátor napíše nápovědu a ono ji to rozparsuje a použije ke zpracování parametrů na příkazové řádce.

Docopt imho nemůže plně konkurovat argparse. Je to dobré na různé jednodušší interface, ale selhává tam kde chceš validaci, defaultní hodnoty a všelijaké vymoženosti, které jsem si už zvykl považovat za standard.

[jas]

Hm, nemylis si to s getopt? Ten git-like UI (iproute2 UI nepoznam) skutocne nedaval a mal aj par dalsich nevyhod (napr. nedokazal rozparsovat len zname argumenty a pod.), ale s argparse sa git-like UI da implementovat celkom pohodlne (cca len staci pridat subparsere) + vdaka ciastocnemu rozparsovaniu je mozne celkom lahko poskladat viacero parserov, pripadne doplnit nejaku nestandardnu funkcionalitu.

[pavlix]

Podle mě jsou subparsery zlo. Jsou až příliš oddělené a nelze pak dobře řešit tak triviální věci jako že nějako command je default a podobné. Už je to dlouho, co jsem to zkoumal, zkoumal jsem to dost pečlivě, a došel jsem k závěru, že je to vyhovující nástroj jen na základní věci a když z toho chce člověk vymačkat víc, tak stráví hromadu času nad věcmi, které by jinak sám implementoval na pár řádků a měl hotovo.

[jas]

Default command v zaklade nie je, ale to nie je az tak velky problem pri argparse. Hlavna vyhoda argparse je snad v tom, ze je dost benevolentne k jeho vstupu a dovoluje robit s nim dalej (prave na rozdiel od optparse), takze mozes kludne implementovat veci nad argparse, ktore argparse nezvlada na par riadkov...

V tomto pripade teda pred volanim parse_args staci nieco ako

if sys.argv[0] not in allowed_commands:
    sys.argv =  [default_command] + sys.argv

btw: Mne pride, ze subparsere su mozno az prilis malo oddelene, napr. zapisuju argumenty do jednej namespace.

[pavlix]

V tomto pripade teda pred volanim parse_args staci nieco ako

1) To něco bude muset být značně odlišné.

2) Nevím proč by v mém software přímý přístup k argv měl vadit, zatímco u software s argparse by měl být v pořádku.

zapisuju argumenty do jednej namespace.

Sám si to už ani nepamatuju, ale to mi teda taky přijde úchylné, i když funkčně to asi není až tak zásadní.

[jas]

1) To něco bude muset být značně odlišné.

Ci to bude musiet byt znacne odlisne zalezi od designu programu, ale pokial argumenty beru az podprikazy, tak to alebo nieco velmi podobne dostacuje.

2) Nevím proč by v mém software přímý přístup k argv měl vadit, zatímco u software s argparse by měl být v pořádku.

Nevadi, chcel som prave povedat len to, ze argparse je proste lahko rozsiretelne a da sa nan pozerat len ako na pomocny nastroj, pouzivat ho v pripadoch, ked dava nejaku pridanu hodnotu zadarmo a o zvysok parsovania argumentov sa moze clovek starat rucne.

[pavlix]

Nevadi, chcel som prave povedat len to, ze argparse je proste lahko rozsiretelne a da sa nan pozerat len ako na pomocny nastroj, pouzivat ho v pripadoch, ked dava nejaku pridanu hodnotu zadarmo a o zvysok parsovania argumentov sa moze clovek starat rucne.

Až budu mít čas, vyzkouším to.

[JS1]

Jsi zbytecne konzervativni, a ten ton.. Proc neco dneska psat pro Python 2, kdyz clovek nemusi?

[Bystroushaak]

Protože je to pořád "průmyslový standard" a trojka nemá kromě pár vylepšení moc co nabídnout. Programuju v pythonu profesionálně a nikde kde mi nabízeli práci o trojce ani neuvažovali.

[pavlix]

Souhlasím, že je dvojka průmyslový standard, ale že nemá co nabídnout, je podle mě kravaťácký pohled. Podle mě narovnává, co se ve dvojce porůznu zvrhlo a tím je pro vývojáře docela dost atraktivní, zvlášť, když se do značné míry daří jeho vlastnosti backportovat na 2.x a pokud by vývojářům Pythonu trochu víc záleželo na prosazení trojky jako průmyslového standardu, tak by ta kompatibilita byla ještě lepší. Zda na to ještě dojde, ukáže čas.

Osobně jsem se bavil s mnoha lidmi ohledně nasazení dvojky a trojky a zpravidla je situace podstatně složitější než jenom že by o trojku v podstatě neměli zájem. Navíc za ten průmyslový standard trochu můžou i průmysloví dodavatelé software, kteří nemají problém s trojkou ještě chvilku počkat a nabízet ji jen jako nadstavbu a nikoli jako integrální součást svých produktů.