Configy pro python scripty - json? yaml? imp!

31.10.2012 12:02 | Přečteno: 1011×

Jasně, nejedná se o nic převratného a tato technika se používa běžně. I tak si myslím že si zaslouží článek, už jen proto že jsem si k ní sám přišel přes JSON a až poté si uvědomil že se o nic převratného nejedná .

Python přímo v základní distribuci obsahuje knihovny pro práci s ini (ConfigParser), JSON (json), balíčky pro yaml (pyYaml) jsou snad v každé distribuci. Já se pro konfiguraci našeho projektu rozhodl použít JSON, kvuli pokročilejší struktuře než jednoduché ini a také protože json modul je součástí standardní python distribuce. Ukázalo se to jako špatná volba, protože jednoduše naimportovat soubor jako python kód vyjde prakticky nastejno a navíc umožňuje používat callbacky, reference atd. Ukázalo se to jako dobrá volba, protože přejít z JSON na import python kódu je až drasticky jendoduché

Předvedu na jednoduchém příkladu s vymyšlenou konfigurací jednoduchého serveru:

Json config:

{
"name":"lucifer",
"listen_ip":"127.0.0.1",
"listen_port":"666",
"requests" : { 
 "/A":"filepath",
 "/B":"filepath"
}
}

Použití z pythonu

import json
conf = json.load(open('config_file'))
conf['name']
conf['requests']['/A']
# ...

Využijme toho, že JSON dictionary je vlastně validní python, takže stačí přidat název proměnné před JSON dictionary a nahradit json za imp a získame všechny výhody (a nevýyhody - musíme teď více duveřovat configum) loadováni přímo python kódu místo JSONu.

config:

config = {
"name":"lucifer",
"listen_ip":"127.0.0.1",
"listen_port":"666",
"requests" : { 
 "/A":"filepath",
 "/B":"filepath"
}
}

Použití z pythonu

import imp
conf = imp.load_source("config","config_file").config
conf['name']
conf['requests']['/A']
# ...

Takto budou configy mnohem mocnější a jednoduše omezíme zbytečnou duplikaci.

Pokud například chceme pustit server jěšte na jednom extra portu a s jiným jménem

Druhý config:

import prvni_config
config = prvni_config.config
config["listen_port"] = "777"
config["name"] = "inferno"

       

Komentáře

[Josef Kufner]

Příliš mocné configy jsou dosti dvojsečná zbraň. Sice umožňují lehce napsat složitou konfiguraci, ale značně komplikují práci s takovou konfigurací.

Čistě deklarativní přístup má výhodu v tom, že můžeš říct, co tam je, aniž bys konfigurák spouštěl. A hlavně existuje funkce, která dokáže načtený konfigurák uložit zpět do souboru, což je užitečné při tvorbě editorů takových konfigurací, neboť editor může načíst a nezměnit části kterým nerozumí (novější verze).

Oproti tomu s programovanou konfigurací neexistuje (tedy alespoň není znám) způsob jak sestavit z načtené konfigurace zpět zdrojový soubor a při tom mít jistotu, že je stejný jako původní (s tolerancí na formátování). Takže případný editor konfigurace nemůže nic, než vygenerovat zcela nový konfigurační soubor a zahodit vše, čemu v předloze nerozuměl.

Ten tvůj příklad by celkem jednoduše šel implementovat zavedením dědičnosti do konfiguráku, tedy volbou "chybějící údaje vem z tamté konfigurace".

Zajímavější by bylo ale přidání volby pro include jiného souboru a umožnit include i výstupu programu (popen místo fopen), takže by bylo možné bezbolestně vytvořit propojení s libovolnými jinými systémy či úložišti/generátory konfigurace.

[smazáno]

Souhlasim, ze tento pristup se neda tak zobecnit, aby nahradil konfigracni soubory vsude . Tady se jedna o konfiguraci pro jednoduche skripty, pro ktere editor konfigurace nebude pouzit nikdy. A proste za danych podminek to je zajimavy reseni

[dumblob]

Oproti tomu s programovanou konfigurací neexistuje (tedy alespoň není znám) způsob jak sestavit z načtené konfigurace zpět zdrojový soubor a při tom mít jistotu, že je stejný jako původní (s tolerancí na formátování). Takže případný editor konfigurace nemůže nic, než vygenerovat zcela nový konfigurační soubor a zahodit vše, čemu v předloze nerozuměl.

Hm, dumam tady jiz chvili nad nevyhodou reseni obycejneho rekurzivniho pruchodu strukturou, serazeni polozek napr. podle abecedy a ulozeni (v pripade kolekce samozrejme nic neradit a zachovat stavajici poradi).

V ukladani a nacitani a pripadnem pouzivani diffu na takoveto konfiguraky by nemely nastat zadne problemy, takze vidim problem akorat v tom, ze se v konfiguraku muze objevit nejaky skodlivy kod nestatickeho (spustitelneho) charakteru jako velke bezpecnostni riziko.

Celkovy prinos tohoto jednodussiho reseni imho ale prevazi pred nedostatky.

[Josef Kufner]

Prostý průchod strukturou nezvládne rekonstruovat ani ten poslední příklad uvedený v zápisku.

[dumblob]

Python mi sice nerika pane, ale presto tam porad problem nevidim nevidim. Asi bych mel uvest nejaky kousek kodu, ale zrovna nemam cas - zitra bych to sem hodil.

Mohl byste prozatim uvest ktery kod konkretne mate na mysli vy a proc konkretne toto by rekurzivnim pruchodem s razenim neslo?

[Josef Kufner]

Vezmi si ten poslední příklad:

# prvni config
config = {
"name":"lucifer",
"listen_ip":"127.0.0.1",
"listen_port":"666",
"requests" : { 
 "/A":"filepath",
 "/B":"filepath"
}
}

# druhy config
import prvni_config
config = prvni_config.config
config["listen_port"] = "777"
config["name"] = "inferno"

A chceš udělat grafický nástroj pro editaci takové konfigurace, aby to měl uživatel jednodušší.

Zní to lehce. Načteš config, zobrazíš dialog s pár políčky, uživatel něco upraví a výsledek zas uložíš.

S prvním configem problém není. Je to celkem jednoduchá datová struktura – pár vnořených hash tabulek, žádný problém. Ale co ten druhý config?

Když ho načteš, dostaneš tohle:

config = {
"name":"inferno",
"listen_ip":"127.0.0.1",
"listen_port":"777",
"requests" : { 
 "/A":"filepath",
 "/B":"filepath"
}
}

To je snadné. Ale hádej, co se stane, když to uložíš? A co se stane, když pak změníš první config?

[dumblob]

Popisujes presne moji predstavu. Ale nejak ze stejneho kodu odvozuje kazdy z nas odlisny zaver.

Kdyz to ulozim, tak dostanu

config = {
"name":"inferno",
"listen_ip":"127.0.0.1",
"listen_port":"777",
"requests" : { 
 "/A":"filepath",
 "/B":"filepath"
}
}

A nejak nepobiram proc bych mel menit prvni config. Rekneme, ze ho zmenim na nasledujici:

# prvni config
config = {
"name":"lucifer",
"surname":"the_big_boss",
"listen_ip":"127.0.0.1",
"listen_port":"666",
"requests" : { 
 "/A":"filepath",
 "/B":"filepath",
 "/C":"some_new_filepath"
}
}

Kdyz tohle nactu do GUI, nic divneho se nestane a bude to v poradku upravitelne. Kdyz na to postvu diff, bude to krasne citelny patch a tedy se take nic hrozneho nestane.

Ano, spatne jsem se vyspal, takze muzu pekne placat, ale proste mi porad nedochazi v cem je problem .

[Josef Kufner]

Máš jednoduchý scénář:

1. Načteš druhý config a bez změny ho uložíš zpět (např. pomocí GUI).
2. Upravíš první config.
3. Načteš znovu druhý config.

Spočítej si, jaký config na konci načteš, pokud první krok provedeš a jaký, pokud ho vynecháš. Jako uživatel bych očekával, že budou stejné.

[dumblob]

Ha, uz jsem te pochopil. Mel jsem na mysli editaci (napr. v tom GUI) takovou, ze bude zohlednovat oba pristupy:

1. jako "zdrojovy" soubor (tzn. neobsahujici zadne include)
2. jako "odvozeny" soubor, ktery meni specifika ze "zdrojoveho" souboru (tzn. obsahujici predevsim include a sem tam neco zmeni/prida/odebere)

V takovem pripade samozrejme neni problem diffovat a upravovat oba typy. Problem je, ze musi existovat nejaka "hlava stromu", coz jsem z clanku pochopil jako vyzadovanou vlastnost .

[Franta]

Ale to jsou pořád jen nějaké hashmapy a pole, ne? Nebylo by lepší používat třídy/instance + mapování na nějaký serializační formát.

[Bystroushaak]

Nebylo by lepší používat třídy/instance + mapování na nějaký serializační formát.

Co by tím získal, kromě pár set řádků zbytečného kódu navíc?

[Franta]

Větší spolehlivost. Používat v kódu literály (v tomto případě "listen_port", "requests" a další) se obecně nedoporučuje (nejen) kvůli překlepům a je tedy vhodné použít místo toho konstanty. Pak se mi to ale rozpadne a rozplizne – někde mám definované konstanty stylem:

CONFIG_NAME = "name";
CONFIG_LISTEN_IP = "listen_ip";

a všude možně v kódu roztroušená volání config[CONFIG_NAME]. A nikde není na jednom místě definovaná ta struktura – v konfiguráku bude zase jen nějaká ukázka, v dokumentaci možná výčet parametrů… ale víme, jak to chodí s dokumentací – jednak není strojově čitelná a jednak se někdy zapomíná na její aktualizaci. Proto považuji za užitečné mít někde (definice třídy/tříd) definovanou celou strukturu konfigurace.

Pak když někde ty konfigurační volby používáš, tak je taky příjemné, když napíšeš instance.vlastnost a IDE ti napovídá, jaké vlastnosti tam jsou + jejich dokumentaci, místo abys střílel od boku nějaké config[KONSTANTA_NEBO_LITERÁL] a doufal, že tam taková vlastnost bude a že bude mít význam, který předpokládáš, doufat, že jsi neudělal překlep nebo nepoužil konstantu patřící do jiného rozsahu (to se sice dá řešit přes různé předpony – ale při větší strukturovanosti je to odporně dlouhé…). Proč vlastně nepoužít OOP, když ho máme k dispozici?

Přijde mi, že jedna třída s pár „zbytečnými“ řádky navíc dokáže ušetřit spoustu dokumentace, příkladů, zbytečného kódu jinde a hlavně nervů a nejistoty (např. překlepy v literálech nezřídka vedou k tomu, že program sice nespadne, ale funguje špatně a na chybu je obtížné přijít).

[rADOn]

To co pises o objektech jsou uplne nesmysly ze kterych je videt ze jsi nikdy v pythonu nepsal :-p Zapis si za usi: Atributy objektu se ukladaji do slovniku. A slovnik sam je perfektni objekt. Z toho duvodu tvoje poznamky bud neplati ani v jednom pripade (treba doplnovani v IDE) nebo se daji aplikovat na oboji (zkontrolovat klice na platnost). Kdyz bych chtel (teoreticky) udelat radost nejakemu skalnimu javistovi tak udelam tohle:

class Config(object): pass
config = Config()
config.__dict__ = literal_eval(read(config_path))

a mas ze slovniku udelanej (uplne zbytecnej) objekt. Bum.

[xkucf03]

Tak to je jazyk dost na pendrek (tušil jsem to už dřív). Tohle je taky problém slepice/vejce. V kódu (kde tu konfiguraci čtu) nevím, co v ní bude, jaké vlastnosti/klíče tam můžu předpokládat. A v konfiguraci zase nevím, jaké položky tam můžu nastavit, dokud se nepoužijí v kódu – ale i když se použijí, tak to asi nepůjde dost dobře rekonstruovat a říct: používají se taková a taková políčka, tohle může mít víc hodnot, tady má být vnořená struktura….

Chybí mi tam to jedno místo, kde by se definovalo rozhraní a jednotlivé části programu by se podle něj zařídily. Přijde mi to takové na vodě.

[dumblob]

Tak tedka jsi prave takrka definoval klicove vlastnosti dynamicky typovanych jazyku .

V takovych pripadech se uvedene "problemy" resi konvencemi.

[Josef Kufner]

Ono pak taky budeš chtít napsat dokumentaci, takže nějaká struktura, která popíše přípustné volby, jejich hodnoty a jejich význam je celkem potřeba. Asi bych takovou strukturu dal parseru a přihodil do ní i funkce, které se mají volat při nalezení jednotlivých voleb (budou krátké a jen validovat a nastavovat, co je třeba). Takže vše bude pohromadě a přehledné.

[xkucf03]

Ono pak taky budeš chtít napsat dokumentaci, takže nějaká struktura, která popíše přípustné volby, jejich hodnoty a jejich význam je celkem potřeba.

No právě. Použil bych třídu + anotace a dalo by se z toho vygenerovat XML schéma a docela slušná dokumentace.

Asi bych takovou strukturu dal parseru a přihodil do ní i funkce… Takže vše bude pohromadě a přehledné.

Můžeš napsat nějakou ukázku? Zajímalo by mne, jak by se tohle řešilo v Pythonu.

[podlesh]

V podstatě podobný princip se používá v ruby a podobných jazycích, někdy se tomu říká DSL. Ovšem ty výhody jsou jiné než uváděné IDE.

[Bystroushaak]

Musím se přiznat, že se mi to docela líbí. Nepřijde mi to moc čisté, ale pomalu se učím nebýt programming nazzi :P

[smazáno]

diky

[nyan]

Ma to malou chybicku - JSON byl vzdy zamyslen jako jednodussi nahrada XML - tj na prenos / ukladani dat, ne na konfiguraci. Tudiz trebars tak jednoduchou vec jako komentar v JSON neudelate (v .py samozrejme jo). Jinak YAML FTW!

[Josef Kufner]

JSON má jednu moc pěknou vlastnost: Když uděláš: json_encode(json_decode(json)), tak dostaneš přesně to samé jako na vstupu (až na nevýznamné bílé znaky). To hodně zjednodušuje práci s takto uloženými daty. Přidání komentářů tohle buď rozbije, nebo neskutečně zesložití práci. Takže vlastně nevýhoda JSONu je jeho výhodou.

Ale na ručně upravovanou konfiguraci se to opravdu moc nehodí. Naopak na konfiguraci upravovanou z nějakého GUI to je super, neboť to zůstává snadno upravovatelné i bez GUI, ale přitom se nic neztratí.

[Franta]

To hodně zjednodušuje práci s takto uloženými daty. Přidání komentářů tohle buď rozbije, nebo neskutečně zesložití práci. Takže vlastně nevýhoda JSONu je jeho výhodou.

V XML je komentář uzlem a není problém je uložit zpět stejně jako ostatní druhy uzlů (textové, elementy atd.).

[Josef Kufner]

Ano, to je to neskutečné zesložitění. XML má dvanáct (!) typů uzlů. JSON má hash tabulku a seznam... a specifikace se vejde na jeden útržek toaletního papíru.

[Saljack]

Mě to přijde jako blbost. Config má nějaký svůj účel. Tohle už je podle mě práce pro samotný program. Jako nápad dobrý, ale už bych to prostě nepoužíval jako config soubor.

[smazáno]

No jo, jsem to moc zobecnil. Jsem proste potreboval udelat z configu spis hezky definovanej mini-modulek do skriptu a libilo se mi jak bylo jednoduchy prejit z JSONu na pouziti 'imp'.

[alfonz]

Jde to používat i opačně? Tedy pro ukládání dat? V současné době používám YAML(je v pohodě, sice pokles rychlosti jde vidět).

Pokud by ale šel tento config používat tak, že mám prostě slovník a jako takový ho uložím do souboru, tak by to bylo skvělé řešení na některé složitější slovníkové struktury hlavně asi co do rychlosti.

[smazáno]

pickle

http://docs.python.org/2/library/pickle.html

>>> pickle.dump({'x':'y'},open('/tmp/yodawg','w') )
>>> d = pickle.load(open('/tmp/yodawg'))
>>> print (d)

[Bystroushaak]

Tohle nejspíš nebude moct editovat ručně, takže to použití jako konfiguráku krapet zabíjí.

[smazáno]

Mohl by specifikovat format pickle 0 "Protocol version 0 is the original ASCII protocol and is backwards compatible with earlier versions of Python."

Ale jasne, jestli tam je pozadavek na rucni editaci, tak bych sel do JSONu.

[alfonz mucha]

JSON se mi právě moc nelíbí, proto používám již dříve zmíněný YAML, ale ten tip co je tady v blogu, pokud by šel používat opačně, tak by to bylo skvělé...

[smazáno]

jeste me napada pprint

[alfonz]

Ano pickle znám, problém je s tím, že nezapíšete to co máte ve slovníku. Chtěl jsem vědět, jak zapsat přímo to co máte v tom configu ;)

[Bystroushaak]

Ano pickle znám, problém je s tím, že nezapíšete to co máte ve slovníku.

?

Vždyť to v pohodě funguje. Na složitější věci je ale asi lepší shelve.

[alfonz mucha]

tak jsem se špatně vyjádřil, nevypadá to jako yaml/json/ a vzhledově to nepřipomíná slovník :)

[Radek Novacek]

Možná mi něco nedochází, ale tohle mi rozhodně nepřijde jako dobrý nápad. Pokud ten proces, který čte konfigurák, běží se zvýšenými oprávněními (root) a konfigurák je zapisovatelný uživatelem, tak je to pěkná bezpečnostní ďoura.

[smazáno]

Samozrejme ze je (vzdyt je to v tom clanku i napsany ).

[Radek Novacek]

Aha, neumím číst Díky.

[rADOn]

A krome toho ast.literal_eval()