I think I am generally in favor.

My main concern is with the locale config. I don’t know how to do this right and this might be the right way, but I remember that we had a lot of portability issues with that stuff. It is unclear to me whether there is any locale which we can reliably expect to exist on all devs systems. But apparently we already use C.UTF-8 at one place so using it everywhere does not seem worse.

Re: Sorting configuration-common.nix

I would argue that if we want to enforce sorting in a human edited file then we need CI to enforce it. What command did you use to do the sorting?

Our previous approach was: add at random position to avoid merge conflicts as much as possible. But sorting alphabetically achieves a similar goal. Main disadvantage I see is that sometimes it makes sense to sort packages topically and of course enforcing it in CI will annoy people.

It is unclear to me whether there is any locale which we can reliably expect to exist on all devs systems. But apparently we already use C.UTF-8 at one place so using it everywhere does not seem worse.

C.UTF-8 is exactly the one "locale" we can rely on. Just C would be even more reliable, but I guess C.UTF-8 is enough nowadays.

I would argue that if we want to enforce sorting in a human edited file then we need CI to enforce it. What command did you use to do the sorting?

CI already enforces it! It's the "keep-sorted" workflow: https://github.com/NixOS/nixpkgs/actions/runs/14646951951/job/41103466827?pr=401492

To run it locally, just do nix-shell -p keep-sorted and then keep-sorted <path>. It will sort automatically according to the configuration comment.

Our previous approach was: add at random position to avoid merge conflicts as much as possible. But sorting alphabetically achieves a similar goal. Main disadvantage I see is that sometimes it makes sense to sort packages topically and of course enforcing it in CI will annoy people.

Yeah, the upside isn't that big. If "random position to avoid merge conflicts" is the idea, maybe we should explicitly mention that instead. It is the same approach mentioned in the release notes - and there I sure don't have the problem of figuring out where to put stuff. Aka, as someone who wants to do stuff "right", a comment telling me "hey, put it in a random spot" would 100% help my first interaction with that file.

Ah, fair enough. Cool.

I am on-the-fence regarding sorting configuration-common.nix.

Pro:

• reduced conceptual overload, especially when new to the file
• slightly easier navigation (nearly moot point in the face of control+f
• sorting might sometimes lead you to find neighboring relevant overrides. First you detect whether there already is an override (which is nearly useless because you will get a nix error, second you find similar named packages, especially versioned overrides for the same package. The last one is the biggest win in my opinion.
• enforced sorting avoids merge conflicts caused by people not respecting the random spot rule.

Con:

• commenting the random approach is easy
• sorting errors increase CI roundtrips

I have really no strong opinion. I like the last two pro arguments, but in the end I fear it is just more bureaucracy.

One more Con:

• The attributes added with inherit (...) ...; are not sorted by their attribute name, but by "inherit".

So the sorting is still a bit inconsistent in the end.

Since the step of sorting this is potentially introducing merge conflicts on it's own, I'll drop that commit and add a note about the preferred random position to the file's header.