Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

featreq: function to filter out overlay packages for supported platforms #4

Open
colemickens opened this issue Aug 1, 2020 · 12 comments

Comments

@colemickens
Copy link

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.)

@colemickens
Copy link
Author

{
      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";
        };
}

@zimbatm
Copy link
Member

zimbatm commented Aug 1, 2020

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?

@zimbatm
Copy link
Member

zimbatm commented Aug 1, 2020

#5

@colemickens
Copy link
Author

Cool, I need to try it and glance at eachSystem but it looks like what I want, yeah. And I like the looks of #5. I'm going to try to re-visit my various flake repos next weekend, maybe dogfood #5 and then comment again / close this out.

@zimbatm
Copy link
Member

zimbatm commented Aug 3, 2020

Looking forward to your feedback!

@colemickens
Copy link
Author

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?

@zimbatm
Copy link
Member

zimbatm commented Aug 7, 2020

You're right. .flattenTree should be changed to take the system as an argument. Do you want to tackle this?

@colemickens
Copy link
Author

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.

@dhess
Copy link

dhess commented Dec 22, 2020

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.

@zimbatm
Copy link
Member

zimbatm commented Dec 22, 2020

^ please try out this new implementation in PR 13

@blaggacao
Copy link
Contributor

blaggacao commented Dec 30, 2020

@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.

@nrdxp
Copy link

nrdxp commented Dec 31, 2020

My solution does check the buildInputs of each flake package for platform dependence, but not recursively.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants