featreq: function to filter out overlay packages for supported platforms
colemickens opened this issue ยท 12 comments
This is what I'm doing now. I know there are more sophisticated versions around that will check dependencies recursively. This seems eligible for flake-utils
, any overlay or package set providers will likely want to use some sort of function like this.
(Bonus points if we discuss whether to filter unsupported platforms out entirely, or if we give a more helpful error in those cases.)
{
packages = let
pkgs = sys:
let
nixpkgs_ = (pkgsFor inputs.nixpkgs sys true);
packagePlatforms = pkg: pkg.meta.hydraPlatforms or pkg.meta.platforms or [ "x86_64-linux" ];
pred = n: v: builtins.elem sys (packagePlatforms v);
in
nixpkgs_.lib.filterAttrs pred nixpkgs_.waylandPkgs;
in {
x86_64-linux = pkgs "x86_64-linux";
aarch64-linux = pkgs "aarch64-linux";
};
}
With today's flake-utils you would achieve something similar like this:
{
description = "colemicken's wayland overlay";
inputs.flake-utils.url = "github:numtide/flake-utils";
outputs = { self, nixpkgs, flake-utils }:
{
overlay = import ./overlay.nix;
}
//
(
flake-utils.lib.eachSystem [ "aarch64-linux" "x86_64-linux" ] (system:
let
pkgs = import nixpkgs {
inherit system;
config = { };
overlays = [ self.overlay ];
};
in
{
packages = pkgs.waylandPkgs;
}
)
);
}
Assuming that the overlay puts all its packages under pkgs.waylandPkgs
, and that pkgs.waylandPkgs
only contains derivations (otherwise nix flake check
complains).
The big chunk at the end could probably be simplified for the common case.
{
description = "colemicken's wayland overlay";
inputs.flake-utils.url = "github:numtide/flake-utils";
outputs = { self, nixpkgs, flake-utils }:
flake-utils.lib.simpleFlake {
inherit self nixpkgs;
overlay = import ./overlay.nix;
overlayAttr = "waylandPkgs";
systems = [ "aarch64-linux" "x86_64-linux" ];
};
}
How does that look?
Looking forward to your feedback!
I'm skimming through the source and #5, I'm not seeing anything that does the filtering I'm looking for based on the meta.platforms
unless I'm looking in the wrong place?
You're right. .flattenTree should be changed to take the system as an argument. Do you want to tackle this?
I can't anytime soon. But cleaning up my flake.nixs will eventually block me and I plan to clean them via this repo, so I'll get to it eventually if you don't. Thanks for confirming my understanding and starting up this repo.
We're slowly converting our overlays to flakes, and something that filters the per-system package set based on meta.hydraPlatforms
would be very helpful.
In our current overlays, we import nixpkgs + "/pkgs/top-level/release-lib.nix"
and use its functionality to build Hydra jobsets. Nix's built-in flake support, combined with flake-utils
, replaces most of that machinery, except for the bit that filters out packages that don't support a particular platform.
^ please try out this new implementation in PR 13
@nrdxp do stars align here? (through PR13). I think nrdxp/nixflk
is a complement use case to look for. Its flake is already quite complex while trying to solve common use cases around nixos configurations.
My reasoning is: flake-utils
is an even higher order abstraction than nixflk
, so moving things up the ladder (where adequate) might perfectly serve the presumptive goal of both projects to set a standardization precedents early on.
My solution does check the buildInputs of each flake package for platform dependence, but not recursively.