roberth
commented
1 year ago Cool. I also wrote this in the meantime
It's not flake-parts-specific, or at least not anymore. It adds a generic module that provides the basic options; no attrsOf. It's sufficient for importing into perSystem, and I've had the realization that importing into perSystem has the benefit of improving laziness of input fetching when perSystem is never used (but for example flake.lib or flake.nixosModules is). This is likely an unlikely benefit, and I hope importing into both top level and perSystem won't cause too much confusion.
So there's some laziness benefit to having a separate nixpkgs module that doesn't need to load a whole version of Nixpkgs just to be ignored later. I think one particularly strong case is the easyOverlay module, as it makes the nixpkgs input completely useless, and so loading it unconditionally is wasteful, and importing in perSystem (instead of a top level module) doesn't change anything about that.
tl;dr separate nixpkgs caller module still good!
In order to let the nixpkgs API develop itself as separate module. That sounds like the direction this project is about. Is that planned and or interesting? Would a separate repo work better, or a local sub-flake? I would think the first option cleaner and lighter when using core-only. Will be working on a separate nixpkgs abstraction in a standalone repo for now, probably coupled with a nixpkgs module at first, to keep the concept in one place. Cheers.
PS. Watch for that Pluto contra-parallel Sun, it's still on for a few weeks, feels as if the fabric of reality is resisting the Heart. It will pass ... :)