non-interactive setup.py

[martinmacko47]

Jednotlive body rob pls postupne v separatnych PR.

• Do setup.py pridaj nasledujuce commandline parametre. Pouzi niektoru zo standardnych python kniznic na pridavanie parametrov, nech sa to sprava predvidatelne.
  • --key=value: Kde key su settingy zo setup.json s _ nahradenymi s -. A value su hodnoty pre ne, ktore sa pouziju ako default hodnota pre dany key. Takto zadana value ma prednost aj pred value ulozenou v setup.json. Na commandline moze byt pouzitych naraz viacero takychto parametrov. Bolo by fajn, aby command mal aj --help parameter, ktory vypise zoznam a popisy vsetky --key=value parametrov a podobne.
  • -i, --interactive: Ak je parameter zadany, tak setup.py sa bude spravat interaktivne ako doteraz. Ak nie je zadany, tak pri vsetkych krokoch, kde sa ocakava vstup usera a je k dispozicii predvolena hodnota z --key=value parametrov alebo precitana zo setup.json, automaticky sa pouzije tato predvolena hodnota. Ak ziadna taka predvolena hodnota nie je znama, alebo nesplna poziadavky, vyziada sa vstup od usera. Nikdy sa vsak nesmie automaticky pouzit uplne defaultna hodnota zadrotovana v kode. Teda napriklad ak sa setup.py zavola prvy krat bez --key=value parametrov a bez existujuceho setup.json, tak user bude musiet explicitne zodpovedat na vsetky otazky. Podobne ked do setup.py pribudne novy key, ktory este v setup.json nie je, tiez bude musiet user nan prvy krat po jeho pridani explicitne zodpovedat. To je koli tomu, aby user nove settingy neprehliadol.
  • -n, --non-interactive: To iste ako nez -i vyssie, ale je mozne pouzit aj defaultnu hodnotu zadrotovanu v kode. Ak predvolena hodnota nie je znama, alebo nesplna poziadavky, a v kode nie je zadrotovana ani ziadna defaultna hodnota, command failne. Mozno to pojde spravit nejakym hackom typu, ze rucne zavrieme stdin. Takze ak sa pokusi nieco z toho zavreteho stdin precitat, tak to failne. Ale kludne to mozes spravit aj explicitne.
• Skontroluj, ci nejake otazky sa nepytaju aj niektore subcommandy volane zo setup.py. Ak ano treba ich analogicky zautomatizovat.
• Pomocou tychto settingov zjednodus volanie python setup.py v .github/workflows/main.yml a misc/Dockerfile. Malo by stacit pouzit nieco ako:

  python setup.py -n --server-mode=local_with_local_mail --mock-libreoffice=y ...
  

  Pricom staci zadat iba tie options, pri ktorych nam nevyhovuje ich defaultna hodnota.

Cielom su dve veci:

• Aby pri prvom spusteni setup.py musel user zodpovedat na vsetky otazky. Ale pri kazdom dalsom jeho spusteni sa automaticky pouzili hodnoty, ktore uz zadal v minulosti. Ak bude chciet niektore hodnoty explicitne zmenit, moze pouzi --key=value parameter, alebo -i pamameter a naspat zapnut interaktivny mod.
• A aby v CI nebolo treba hackovat vstup, ale aby sa dal pouzit kompletne neinteraktivny mod.