Nix-pkgset is a lightweight library that helps package nix derivations into cross-compilation aware package sets by splicing packages in the same fashion as nixpkgs.
Design goals:
Adopt the packaging conventions of nixpkgs as much as possible (scopes, splicing, pkgs<build><host>, pkgsCross, etc.)
Avoid re-instantiating nixpkgs (use lib.makeScope instead of overlays)
WARNING: The library is still in proof of concept stage and the API is subject to change.
My understanding of nixpkgs scopes and splicing is still pretty limited so it’s possible that some of what I’m doing is insane. I would love to get some feedback on this, especially from nixpkgs maintainers responsible for scopes and splicing. My hope is to eventually have something similar upstreamed to nixpkgs.
I love this direction. It presents a simpler interface to people and a potential to standardize how nixpkgs itself does this.
I’ve been playing and implementing a very similar set of ideas of leveraging makeScope, package sets, and reducing the cognitive load compared to overlays. I’d love to discuss if you have a chance.
@tomberek Excellent talk! I wish I saw it earlier cause I really like the idea of composing recipes over packages. I also share your pain of naming some of these concepts.
I’ve been playing and implementing a very similar set of ideas of leveraging makeScope, package sets, and reducing the cognitive load compared to overlays. I’d love to discuss if you have a chance.
Would love to see what you’ve been up to and possibly join efforts. If you’d like to reach me, you can find my email in the nixpkgs maintainers list and I can also share other contact methods there. For any comments on nix-pkgset feel free to open issues on Github as well.
Has there been any progress in this area recently, in nix-pkgset or other people’s attempts in the same area?
I like the approach here, the proof of concept status makes it a bit unappetizing to use.
This would make a new package set based on the scope of pkgs. And also include:
pkgset.foo (a pre-spliced packageset if you wanna avoid callPackage when doing cross-compilation. Equivalent to pkgs.__splicedPackages)
pkgset.fooBuildBuild, pkgset.fooBuildHost, pkgset.fooHostHost, pkgset.fooHostTarget, pkgset.fooTargetTarget for when you want to access unspliced package variants.
Other features like mimicking pkgsCross and merging package sets I would probably throw away for simplicity’s sake.
This is what I’ve been using for a while now, but I haven’t updated the library yet. I can do this soon.
I’ve updated the library to the first release candidate for a stable release. The API for makePackageSet has changed and there’s no more merging of package sets. Instead each package set is named so they’re still accessible if you layer them one on top of the other.
I’ve been using a similar setup for a few months now so I’m pretty happy with the API.
I’d be happy to hear some feedback and then stabilize this.
Giving it a shot, is there an intended way to expose the scope in a way that it can be instantiated on top of an arbitrary nixpkgs instance eg for cross usage?
Some options, exposing a flake attr mkPkgset = pkgs: nix-pkgset.lib...., or having the flake’s legacyPackages output have .override available so you can do .override { pkgs = myPkgsCross; }. Although I guess that’s slower since the original nixpkgs had to be instantiated first?
Maybe you already intended a particular way and I skipped over it.
From the “1000 instances of nixpkgs” perspective having a standard/recommended way in the README to instantiate someone else’s flake that uses this lib’s pkgset on top of an arbitrary existing pkgs instance seems like a good idea.