Describe the Bug
TOML supports "dotted keys", that is about the same as our "dotted notation" when accessing facts.
Our stdlib::to_toml() uses toml-rb code, that has the issue when dealing with dotted keys.
I hit this when following the puppet-grafana's LDAP config example. It uses toml gem at the moment. When replaced with stdlib::to_toml() it produces a broken TOML.
As I see from unit tests, to_toml() expects a proper Puppet DSL Hash, while toml gem can work with dotted keys.
As a consequence, it's impossible to just replace TOML::Generator with our to_toml() function, because example syntax uses dotted key instead of a nested Hash or Array.
Another problem is sections reordering. E.g. [servers.attributes] section goes before [[servers]], which is wrong.
Expected Behavior
- It'd be nice if dotted keys wouldn't be quoted.
- It'd be nice if sections wouldn't be reordered.
Describe the Bug
TOML supports "dotted keys", that is about the same as our "dotted notation" when accessing facts.
Our
stdlib::to_toml()usestoml-rbcode, that has the issue when dealing with dotted keys.I hit this when following the
puppet-grafana's LDAP config example. It usestomlgem at the moment. When replaced withstdlib::to_toml()it produces a broken TOML.As I see from unit tests,
to_toml()expects a proper Puppet DSL Hash, whiletomlgem can work with dotted keys.As a consequence, it's impossible to just replace
TOML::Generatorwith ourto_toml()function, because example syntax uses dotted key instead of a nested Hash or Array.Another problem is sections reordering. E.g.
[servers.attributes]section goes before[[servers]], which is wrong.Expected Behavior