Why am I getting "system.stateVersion is not set"?

[TLATER]

You misunderstand my point. I’m well aware of the whole “perfect being the enemy of good” dichotomy. This is not a problem of the environment.stateVersion error not being verbose enough, it’s a consistent behavior across all errors thrown by the NixOS module system. If you hit any non-syntax/nix type error you end up in this situation:

@jakubgs

When evaluating a configuration for a fleet of servers you get flooded by “there’s an issue, good luck finding it sucker” warnings all over the place. Not a great user experience.

If code consistency is concerned, your PR is tantamount to adding a new policy stating that the hostname should be added manually to every single warning or error thrown by the module system. Whatever edge case you’ve hit here can be hit in many, many ways through other modules.

My issue is that even if we were to add such a policy, it’s not very helpful. This only helps people crossing hostnames within a single eval, and only if they don’t realize they can evaluate a subset of what they were trying to evaluate to figure out where the error is, and only if they have a mental association between that hostname and whatever they did that could cause this really specific error. I’d be mildly surprised if this even helps you with the error you have right now.

I think educating people (including you) on this quirk of the module system is a far more sustainable solution to the problem, assuming that just fixing the module system isn’t possible.

In simpler terms, you’re throwing some duct tape on a single hole at the end of a pipe with a massive burst in it because you think that hole might cause water to drip somewhere. Sure, you can kind of call it “making it better”, but it doesn’t actually help anyone else and neither you nor others will actually learn how to work with the fact that you’re using a burst pipe.

@jakubgs

Yeah, i get that, and Nix could simply have a debug build of the interpreter that you use when you do want to sacrifice the performance for debugging power.

No, sadly that wouldn’t really help. The issue is the module system, i.e. the thing we really call “NixOS”, besides all the modules written on top of it. It does not push enough information down the evaluation pipeline to actually display more sensible errors. Nix can trace the eval path, but this doesn’t help in practice since it’s really not human readable.

The NixOS module system isn’t directly supported by nix, it’s a fully separate piece of quite impressive engineering fully written in nix, the programming language - unfortunately this separation also means that it doesn’t have particularly great performance characteristics, because nix isn’t really intended to be a super speedy programming language.

Many of the issues in NixOS stem from this separation, the issue of module system errors probably being the most impactful one.

[jakubgs]

I understand my PR is just a hack in a sense, but I still think it’s better than nothing. I’m happy to hear how I can make it better. Probably adding some sort of fallback when name is not set is the first step.

As for the issue with NixOS modules, as I said, i guess the tooling just isn’t mature enough to help debug this problem properly and the only real solution as you say is just stripping things away tediously until you find what stops the warning from appearing.

And in that sense this thread has fulfilled its purpose. My original thought was “surely there’s some clear way to figure out what’s causing this and I’m just not educated in Nix tooling well enough to debug it properly”, but you guys have confirmed to me that indeed this is a common problem and there’s no clear solution to it. Which is a learning in and of itself. Appreciate it.