Is there some sort of popularity requirement or anything of the sort to merge a module, as in, something you can interact with directly in something like configuration.nix or so, I was thinking about making an application you can change some settings directly in nixpkgs. But I assume there has to be a prior popularity requirement?
There is a pseudo-requirement for packages, which suggests that if the software you’re packaging is only going to be used by 5 other people, it’s likely not worth merging it into nixpkgs.
However, only a few committers even check for this, it’s mainly by 2 ways:
- Package request issues
- Stars on the upstream repo
My guess is that the same “requirement” applies for modules too
There aren’t any strict rules and everyone does this differently likely but when I see a package addition, I usually take a look whether it looks like something people would actually want to use or whether it’s just someone’s Saturday afternoon project.
Modules typically don’t have that issue because the package always comes first; a module doesn’t really make sense to have without the package.
If you know that your module isn’t something that’d be used by many people, why not just make it in your own config first? It’s a NixOS module in its own right like any other. The only difference between your config and upstream NixOS is that others get to use it; there are no technical limitations.
I also don’t quite understand what you’re actually planning to do here.