On Thu, Apr 23, 2020 at 06:46:09PM +0200, Andrea Bolognani wrote:
On Wed, 2020-04-22 at 15:28 +0200, Erik Skultety wrote:
> This series is trying to consolidate the number of config files we currently
> recognize under ~/.config/lcitool to a single global TOML config file. Thanks
> to this effort we can expose more seetings than we previously could which will
> come handy in terms of generating cloudinit images for OpenStack.
>
> Patches 1-4 patches are just a little extra - not heavily related to the series
> See patch 5/13 why TOML was selected.
First of all, thanks for tackling this! It's something that we've
sorely needed for a while now.
Now, I know I'm the one who suggested TOML in the first place... But
looking at the series now I can't help but think, why not YAML? O:-)
To be honest, even before you originally mentioned TOML, I myself had INI in
mind, so then I thought, yeah, why not go with TOML then, it's similar and more
powerful.
I did some comparison of several formats, because like you say, with YAML we'd
be more close to Ansible and I was on the cusp of choosing between YAML and
TOML and I felt like TOML was still more readable and expressive in terms of
simple configuration (and that's what Linux users are IMO used to from INI).
I was never a big fan of YAML really and when the dictionaries and list happen
to intertwine and nest a lot, YAML looses its readability quite quickly IMO,
which I never felt with TOML, but it's fair to say that my TOML experience is
very limited. That said, I don't expect us to have such a massive config, so
that multiple levels of YAML nesting will be necessary :).
Since we're using it extensively already due to Ansible, I think it
would make sense to use it for the configuration file as well. It's
easy enough to consume for a human, and we wouldn't need to drag in
an additional dependency. I also believe, perhaps naively, that
adapting your code to use YAML instead of TOML wouldn't require much
work - from the Python point of view, you basically end up with a
dictionary in both cases.
Feel free to argue against this suggestion! For example, if you agree
with it in principle but feel like it's unfair of me to ask you to
rework your code, I'm happy to port it myself.
I'd still prefer TOML, but I don't really have a compelling reason to argue
against YAML other than readability which I already admitted to be just a
matter of taste. Now on a more serious note, I'll wait for your detailed review
and then rework it in YAML in vX.
As for the rest of the series - I've only skimmed it so far, but I
did not spot anything horribly wrong with it at first glance. I'll
provide an actual, detailed review next week.
Okay, thanks.
--
Erik Skultety