Another target that would benefit from this are containers that need configuration independent from NixOS modules since they don't support systemd etc.

True; I am not sure what publically available codebase should be referenced as an example. My real use case is not even in the list and it is closer to what you say about containers; on the other hand, highly-visible existing parallel efforts are more convenient to discuss.

Option generation is also useful for override, such as pkgs.rofi.override = { theme = <file>; }

True. But the packages are shared just fine already anyway, so not a strong motivation. Wrapper packages can already be done easily enough. If implementation turns out to be a huge success we might discuss this on a case by case basis whether to move stuff to the configuration file generator library, but let's get there first.

Is this typed?

Yes, the type is provided next to the generator function.

An example how this would be integrated into NixOS modules might be helpful.

Hmm, I am not sure it can be done easily without integrating an entire example from #42 and then extending it…

What is this type for?

Well, the output is intended for use with an RFCs#42 implementing NixOS module, to put into (in the simplest case) services.<service>.settings. In the simplest cases one can just have a static type for the settings entry, but I guess it doesn't hurt to repeat it here and to allow, when necessary, some variation (depending on configuration format input option, I guess)

That deserves introduction and propper reasoning in the detailed section, then?

Well, we promise to provide type specification and serialiser.

What is a "scoped use of the module system"? Maybe affording another sentence for the message would do.

Scope in the sense of visibility… reworded

I want to add, that in my use case, I would have an interest in that configuration management (as a shared resource) in nix would compound different APIs, like:

• filesystem API (configuration files)
• socket based APIs (fully dynamic service configuration)

→ It might still be useful to apply fully dynamic service configuration declaratively through nix.

Examples of such configuration APIs are:

• network gear TCP endpoints that respond to yang or netconf
• k8s APIs
• ldap configuration (set of boostrapping data after handing off data management to the ldap specific UIs)

It might be out of scope for this particular RFC, though it might be worth including in future work.

I am not even sure it is in scope for future work!

Sure, that's a good idea in general, but this RFC is about sharing something that is already written now, and in a format that has seen some use by now. Inventing on-start configuration for things without persistent configuration is a good direction of work, but it is somewhat different type of work than described here.

You are right maybe "future work" is too normative. Would you like to add a "broader context" (or a better naming!) section at the end (as an after thought)?

As the design uses a module system, putting configuration generators next to packages is also
not a perfect solution; also a configuration generator might end up generating
a set of config for a combination of packages.

→ for terseness sake, that might entirely go into the alternative section?

Good point.

This is not clear to me. Would that be something comparable to a templating approach with variable substitution?

What you say is a reasonable implementation of this abstract interface.

(or some ore appropriate folder name)

I do not think configs is a perfect name, but maybe it is good enough, so let's see if there are other opinions. In principle, that could be left to implementation step, should only lead to a little bit of bikeshedding

Agree, maybe you can change it to "folder subtree" to differenciate the token from "attribute subtree" below.

Hmmm. Indeed an identifier conflict, thanks. Reworded a bit.

NixOS module system based «subtree»

Does it take the subtree as input (as I understand it: it's path — since above sibtree referred to a path) or rather does it take the (lazily) evaluated attribute set corresponding to current config? (I'd induce the latter is what's intended here).

Well, the value of the subtree? A possibly nested attribute set, yes. But not to entire config, just to the service.

So here you could use "attribute subtree" to differenciate from "folder subtree" above. That would help to not get confused.

Hm, maybe indeed worth expanding.

«well-known» is factually wrong here for some of the more interesting configuration file formats.

Oh, that was my interpretation of logSettings question on RFC42.

I changed the suggestion and eliminated well-known. It should be still a little clearer that way.

Move this up to where the detailed idea is presented. At this position, I got almost confused as if it was an afterthought.

It is still detailed-design section. We define the function, and what else is provided. In a sense, it is an afterthought, or supporting scaffolding.

With the removed non-terse interlude this notion is now close enough to it's object (the functions). I reformulated for conciseness sake.

"Provided along with the function." can mean many things (including providing when calling).

"specified along with the function definition" is much less open, though still not perfect.

Somewhat reshuffled everything in the paragraph.

Why? (what for) → you might want to clarify to improve intelligibility here.

Anyone interested in this future work item now is likely to be aware of the context like passthru.tests; those who are not familiar with that will wait anyway until some detailed work is started

Your response is a little bit enigmatic with regard to rhe matter of the question, but let's make some assumptions at the risk of requiring further clarification:

Do you consider here the possibility of moving service configuration still closer to the packaging itself?

If that is the case, the (new) proposed module system for packaging might come into play. And (very) early coordination with this RFC might benefit future development.

We'll see from feedback, but currently the RFC argues against moving configuration generators close to packages. However, we might consider developing a way of having some kind of cross-references available at evaluation time.

For some reason 0072-commonmark-docs.md is part of this RFC, could you remove it?

Squashed the edits until now. Seems to have helped.