I wonder why nixos-hardware isn’t mentioned more prominently in the NixOS documentation, or even incorporated into the nixos-generate-config command. In this case it wouldn’t have helped because there is no config for Latitude 9430 in that repo yet, but I imagine that it can make the installation experience smoother in lots of cases.
I believe that some of these external projects should be phagocyted, included inside the monorepo. They should be as easy to access as nixos/ is nowadays.
The problem with nixos-hardware, in my opinion, is that is looks like a blob of hacks and workarounds for bad hardware.
How should we include it in the monorepo? Certainly it should not be “preinstalled”, but it should not be hidden either.
How should they be tested? Should we ping contributors with weird hardware? Should the modules be kept forever?
I’d be totally in favor of wrapping the nixos-hardware hacks into modules shipped with NixOS such that they can be enabled as needed. I think the problem is primarily that it would be quite a bit of work to make that nice, and “ain’t nobody got time for that”.
Maybe as a first step, can we ask maintainers and users whether there are any blockers to do that sort of upstreaming in principle? When there are no objections, it’s less likely a waste of time to make an attempt and see how involved it actually is.
I’d love to see it refactored a bit if/when this happens, currently nixos-hardware modules are not very composable because they are designed to be used with imports and don’t really use the NixOS module system. There’s lots of copy-paste code duplication because of that, and I’ve seen issues fixed in one place but not another. It’s hard to fix that while maintaining backwards compatibility, moving things to nixpkgs would be the ideal moment to do so.
Other than that I don’t see any issues with this, getting more people’s eyes on it will solve more issues than it causes. There’s enough half-broken and poorly maintained packages in nixpkgs, I don’t think these modules would make things much worse, especially if they’re clearly separated.
To help with maintenance, some kind of script that just evaluates all entrypoints and ensures that there are no differences in the actual evaluated config would be great. Maintainers usually don’t have the devices in question to test, so that kind of “test” is the only way to make sure things keep working.
Then we you have a work to be made before merging it over NixOS/nixpkgs/hardware-quirks.
Namely, getting it in a suitable shape to be included as a PR Train over Nixpkgs monorepo.
Besides incorporating nixos-hardware into nixpkgs which seems a big and controversial topic, what do you think of at least mentioning nixos-hardware in the NixOS documentation? That seems like a way smaller step to take, and also beneficial.
One of the critique points of nixos-hardware is and was back with the RFC that it also includes a lot of information that could be also automatically generated - Profpatsch already tried to merge nixos-hardware in the past and it got reverted again. That’s why my current plan is to upstream modules in nixos-hardware/common at master · NixOS/nixos-hardware · GitHub to nixpkgs and than have tools auto-generate the information. This would allow us to drop this information from the NixOS configurations in nixos-hardware itself.
For a user not having nixos-hardware in nixpkgs is probably an inconvenience. For a contributor at the moment I would argue, it’s a lot easier to get changes in. It’s i.e. easier to have a smaller and faster CI and I personally as a maintainer have a better overview which pull requests can be merged. In nixpkgs everything just gets drowned under automated nixpkgs updates. I don’t know how we could fix that in nixpkgs itself.
I like that approach and even if we merge nixos-hardware into nixpkgs, it would be valueable to have documentation already being written. Let me know if you have any pull requests that can be reviewd. So far what I did was adding links to the repository in nixos-generate-config - so when users generate their configuration they get pointed to it. However it should be also part of the installation manual.
I like @TLATER’s idea of referencing nixos-hardware in a comment in the config generated by nixos-generate-config. I can try to create a PR for that.
Regarding nixos-generate-config, I think we should include it not only in the instructions for the initial installation, but also suggest to run it upon upgrading to a new NixOS release. I remember that after one NixOS upgrade I couldn’t control my backlight brightness any more, and it helped to re-run nixos-generate-config and merge the result into my existing config.
