Expose the config collection outside the module system

[blaggacao]

Is your feature request related to a problem? Please describe.

I have a use case that allows manipulating config data via a simplified divnix/data-merge, which is essentially a glorified recursive merge with semantics to deal with lists.

In order to be able to leverage purely this catalogue 's config data, without the integration complexity of the module system...

**Describe the solution you'd like***

I want to export the raw config data no longer coupled with the module system as the choice of integration. Even if the module system adds definitive value on top, the raw collection maintained by the treefmt community has independent intrinsic value.

In practice, I may propose a ./data folder where the raw data is exposed and then imported into ./programs to conform to the current configuration interface. But also directly exported as data in the flake outputs.

Describe alternatives you've considered

Make a complicated wrapper, that is hard to maintain in order to reverse engineer the module system to get to extract the raw data.

Additional context

I've been starting to accumulate some in-tree presets in divnix/std out of lack of knowledge of a better alternative, like this repo.

It makes use of nix-community/nixago to write the file and the treefmt raw preset currently looks like this: https://github.com/divnix/std/blob/main/cells/presets/nixago/treefmt.nix

It is enriched with the packages information here.

Repeating the excellent curation & collection work of this repo in std is non-sense. I'd rather prefer to point further contributions here.

Here you can find an example useage of this simplified & compact data handling pattern. Maybe you may see how this is motivated by sticking as close to the raw data as possible avoiding any data abstractions.

I'll explain data merge a little further, since it might not be well known:

Data merge merges two data-structures (lhs & rhs): data-merge.merge lhs rhs. The difference with lib.recursiveUpdate is that a list isn't handles unless you decorate the rhs with a merge annotation. E.g. data-merge.merge lhs (data-merge.decorate rhs {a.b = data-merge.append;}). Here a.b on the left hand side is a list.

By using this technique, we can assemble the treefmt configuration root by keep on merging right into left until we end up with the final config.

[zimbatm]

-

[blaggacao]

to come up with something actionable from it.

Maybe...

• a) sounds good, go ahead

or

• b) nope, we don't bother to decouple the config data from the module system