The new format is based on the existing wrapper and generates an INI file with an unnamed global section at the top as is used by *stunnel* for instance.
Technically the INI format is a subset of this however testing, type checking, and API guarantees profit from two separate generators.
Co-authored-by: tim-tx <tim-tx@users.noreply.github.com>
Signed-off-by: benaryorg <binary@benary.org>
Tests using `shouldFail` (new) enable testing for whether the type system catches any unintended uses (missing parameters or unavailable data types in the format).
It should not be necessary to test for all possible outliers for each format, however format-specific tests (for instance those using a rigid submodule structure) can ensure that common mistakes err out instead of being silently discarded, while also allowing test-driven development of sorts.
Signed-off-by: benaryorg <binary@benary.org>
Previously, this test would verify a writeText file with a constant
content is at a precise store path, but this is not actually the case
and the store path has changed maybe twice since the original
"pkgs.formats: Add libconfig format generator" PR was started, the
latest time being after it was merged.
We now placehold the store path in expected.txt and substitute it just
before we run the diff, alleviating the problem.
The way `(lib.formats.yaml {}).generate` generates YAML is compliant
because on YAML 1.2 spec JSON is a subset of YAML but it bugs people's
minds and can lead to problems with software that is not compatible with
YAML 1.2.
This commit also changes the test of the generation function. Data
validation/typing remains the same.
See #133802.
Signed-off-by: lucasew <lucas59356@gmail.com>
Foremost, the message was discarding double quotes on one side of the
diff, which was super-confusing to me, as I thought that the format
convertor broke that when in fact only whitespace was changed.
I thought I'd cat the files, but then... switching to `diff -u` seemed
self-sufficient. It felt sufficiently non-controversial to push
directly, but certainly feel free to improve further.
