Alternative idea: maybe recognizing lib as a "known but unchecked" flake attribute was a mistake and all flakes should use a different attribute name, library if possible. Nixpkgs would then have

• lib (soft deprecated?),
• library.lib,
• library.nixos (current lib.nixos),
• library.nixpkgs (Add Nixpkgs entrypoint lib, <flake>.lib.nixpkgs.configure, (import <nixpkgs>).configure #402298).

(or libraries, or libs)

I think the alternative idea sounds maybe better. It's certainly really confusing that nixpkgs lib just has some random nixos bits overlaid on top of it but only when using it from a flake. Without those bits it's pretty clear what lib is in nixpkgs.

Part of why this is so weird is precisely because of the rigid flake output schema and the flake output schema requiring that you call the library stuff lib which is confusable with nixpkgs lib, the thing that everyone knows about. So it seems to me that the less confusing solution is to remove the namespace collision, perhaps by making lib in the flake just the normal nixpkgs lib and moving the nixos bits into a different attribute name that violates the flake spec, which, whatever, loads of violations of that thing around; I grant I have little care for strictly following the flake output schema given the numerous other design flaws. Alternatively they could both be moved into a libraries output and thus break more people.

Having the libraries output (with a lib subattribute) be called lib is confusing because most people see nixpkgs.lib and they think pkgs.lib, not a secret other thing called lib. There's multiple things called lib in nixpkgs to be sure, like haskell.lib, but that one's called hlib conventionally and thus isn't particularly confusing.

• flake: Add libs #413205