Nix eval --json failing on packages and obsolete options

I find nix eval of an option of my host configs especially useful when I want to make sure what’s actually being applied, and the –json flag combined with a pipe to jq makes it easily readable.

The problem is, –json fails when it tries to eval a package and when it tries to walk through obsolete options (even though I didn’t explicitly set any), which is always the case when I eval a high level host config option. And without this flag, the result is difficult to read.

Wouldn’t it be nice if we had something like an additional –ignore-failed flag that would just skip any nodes that trigger an error either when evaluated or when converted to json ?

Or is there already a way to achieve this result that I’m unaware of ?

Honestly, even with a system like that, serializing an entire nixos or hm config (or even a sizable part of one) is a really bad idea. The module system really depends on the laziness a lot, so walking the entire option tree is going to do a lot of computing that isn’t relevant to your actual config. Finding the values of all those options for modules you haven’t enabled isn’t what you want to be doing. Also, if there’s an error in the part of the config that actually should get evaluated, this system is going to show that error in the form of missing options, which is just plain confusing.

I recommend using the repl to interactively explore option values instead. (Nixos has a nix command to open such a repl: nixos-rebuild repl.)

1 Like

If you can handle the Nix codebase, I’d be happy to pair on this PR that would help with that:

You can try the nixos-option command to explicitly check a given option.

Thanks for all the suggestions. For the use case I have, @mightyiam ‘s PR looks like it’s exactly what I am looking for. I’m unfamiliar with both the nix codebase and C++ unfortunately, so the best I can do is try it out and give some feedback once the merge conflict has been fixed.

1 Like

Besides the merge conflict, it’s simply not complete yet.

1 Like

If your main interest is “what’s actually being applied” when using an option, I recently hacked together this small tool that might help? It’s not exactly what you’re looking for since it’s focused on diffing, but some small tweaks to the python script would let you dump a json of all of config that’s actually used

edit: I updated it to let you output the json from a configuration.config instead of just diffing two

That’s actually a great tool !