nix.conf.json

[roberth]

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

The config format is a bit fragile. Let's use semi-structured data instead. This enables us to accept more complex settings where it makes sense; for instance a JSON object ("attrset") would be great for configuring individual stores.

Describe the solution you'd like

Allow "nix.conf" to be specified in JSON instead.
nlohmann_json has support for stripping out comments.

No more escaping, no more text parsing, and support for a wider range of values. Great compatibility with the Nix language as well.

Describe alternatives you've considered

Configuration formats like YAML, TOML may be considered. These aren't quite as easy to generate or parse.
YAML is too fragile (Norway problem, etc)
TOML would bias our data model away from composable structures.
Nix is not actually easy to generate from Nix, and needing an evaluator to configure the evaluator would complicate initialization.

Additional context

• Triage and break up the global settings #5638

Priorities

Add 👍 to issues you find important.

[grahamc]

I'm interested in this, too, especially for the Determinate Nix Installer's curing support. We've put together a nix.conf parser in Rust, but we definitely would not mind a more clear configuration format.

I'd like to propose we start by saying it is json5, though!

[edolstra]

This would also allow getting rid of /etc/nix/machines, since it could be replaced by a structured representation in nix.conf.

[cole-h]

I'd like to propose we start by saying it is json5, though!

The problem with json5 is that it would require integrating yet another JSON library, since nlohmann_json does not (and will not) support it: nlohmann/json#150

[Ericson2314]

@cole-h we can preprocess it I think and then still use nlohmann_json.

[roberth]

Full JSON5 would have been nice, but comments can already be stripped by nlohmann_json. The other JSON5 features aren't nearly as important I'd say.

[MrFoxPro]

I think it's very important to have a single format, right now there are .conf and .json.
My preferences: Nix (lang) > TOML > JSON > YAML.

[NobbZ]

A problem that I see with all the formats: How do we deal with imports? The effect of include and !include do depend on their position, if there are "overlapping" configurations IIRC.

And as far as I remember, objects/sets/dicts/whatever are unordered in all of JSON, TOML, YAML, and nix. Neither are they able to express the same "key" twice. So even by adding the option "includes"/"!includes" and making it a list, there was no way to express the following:

include pre.conf
experimental-features = nix-commands flakes
include post.conf

So whatever we do, we might have to consider this when designing the new format, or allow to somehow mix both, such that we keep an old style entrypoint to the configuration, which includes JSON and old-style configuration fragments alike.

[roberth]

objects/sets/dicts/whatever are unordered

They're also unordered in Nix, so that's fine.

Neither are they able to express the same "key" twice

I'd consider that a feature, although we need something for extending/overriding. More on that.

include pre.conf
experimental-features = nix-commands flakes
include post.conf

This doesn't strike me as a good format, and overriding is about the least declarative thing, fwiw.

We do seem to need a facility for overriding and extending. How about something standard like JSON Patch?
It's not any more declarative, but at least it doesn't pretend, it isn't yet another custom thing, and it has great library support.
We'll want to minimize use of lists, because those are hard to merge, both in JSON Patch and in the NixOS module system.

As for the syntax, I don't think specifying it in the actual files is really necessary, but we could support that, e.g.:

{ "include_after": [ "~/.config/nix/nix.conf.json" ],
  ... some actual items ...
}

include_before would be unnecessary, but could be added nonetheless.
If you need to include something in the middle, then you could split one or more of the non-include sections into a separate file.

[Ericson2314]

I would not mind simply not supporting include/!include in the first version.

[NobbZ]

This would be very sad, as I use that to be able to set access-tokens through a generated file that only exists in /run/secrets.

To be honest, I do not care for the "before", "after" or "inmidst" semantics, for me any would be fine, as I do not set access-tokens anywhere else than in this file, and at least in my case there will be no conflict. As long as I can include at all I am happy, I just wanted to raise awareness that some certain type of user might be struck by a breaking change.