Wild idea: How about splitting nixpkgs and nixos?

Example of an instance, where the requirement of same-PR priority between pkgs and nixos upstream-downstream relationship is heavily penalizing other possible down streams.

I did an experimental carve out of nixpkgs.lib for flake users.


I appreciate the experiment, there is nothing better than going hands-on. Let’s see, adoption will tell how much value people attribute to it.


It would also be (academically) interesting to extract pkgs/pkgs-lib and it’s secret twin the pkgs/build-support, conceptually they are on the same layer of packages dependent library functions. They could well go into the same conceptual bucket as builtins.

Can anyone enlighten me about the associated costs of providing pkgs dependent library function with different pkgs version than the (potentially the same) packages they actually would build? (besides the obvious downside of increased closure size).

1 Like

In other words, is there a significant cost to building a different version of git than the version that was used to fetch it’s source?

1 Like

Just found a comment that ties in here:

Further down the thread people express their viewpoints against splitting, but this conversation is embedded in an issue with a slightly distinct topic so the comments are spread out.