It seems clearly preferable for both quality and speed of development to have projects like home-manager in their own repositories, since then 1) you can have whatever process is appropriate for a project of that size (e.g. you don’t have to go through the Nixpkgs PR / release process); and 2) you don’t have to give 100+ Nixpkgs committers write access to your project.
Oh, no, I definitely agree that some of home-manager should be in its own repo. That allows for a lot more flexibility than if the codebases were more tightly coupled.
- there is frequently some tight coupling between packages and modules (e.g. if the systemd package is upgraded, it often requires changes to the systemd modules as well). Point 2) is probably not very applicable to home-manager.
Ah, this is where I disagree. NixOS modules and home-manager are very closely related and don’t always interact well, especially for some of the duplicated functionality I listed above.
Regardless, I think we can agree that home-manager+nixpkgs will always be ahead of just nixpkgs. My question is, when nixpkgs wants to implement something that home-manager has, if there could be a process for merging one of home-manager’s existing modules instead of re-inventing the wheel.