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

Flake's overlay should use prev instead of inputs.nixpkgs... ? #20

Closed
PaulGrandperrin opened this issue May 11, 2022 · 8 comments
Closed

Comments

@PaulGrandperrin
Copy link
Contributor

The flake's overlay should use prev instead of inputs.nixpkgs... ?

Maybe I'm mistaken about what is expected from overlays, but I thought overlays should work this way and not pull pkgs from the outside.

Anyway, it makes integration with my system a bit harder, the only solution I found so far is to directly use pkgs.callPackage on nix-alien.nix to force the use of my system's pkgs.

Maybe my needs are weirds also, I can explain more if needed :)

@thiagokokada
Copy link
Owner

Maybe my needs are weirds also, I can explain more if needed :)

I think a PR could explain better what you actually want 😅 ?

@PaulGrandperrin
Copy link
Contributor Author

ok ok :) I'll do that tomorrow (it's too late in france rn)

@thiagokokada
Copy link
Owner

But after re-reading your comment. Yeah, you're completely right 😅 .

I am not sure why I got to this code. I do remember that it was kinda difficult to get poetry2nix to be injected correctly without actually exposing it to the Flakes (that I didn't want).

Anyway, PRs are welcome.

@thiagokokada
Copy link
Owner

thiagokokada commented May 17, 2022

Fixed with commit f313de0.

The overlay now uses prev for poetry2nix and final for pkgs. The reason for this is because thanks to some issue that I am not sure what is happening, if I used pkgs = prev; this would result in a glibc rebuild at every dependency update. So while the solution is not ideal (the overlay now depends on both prev and final), it works. Also it is not that bad I think since final is only used by non-Python dependencies in this context.

Also, I had misunderstood before what nixpkgs.lib.composeManyExtensions function does. It doesn't seem to actually expose poetry2nix in the final overlay, so it seems to be fine for me.

@PaulGrandperrin
Copy link
Contributor Author

Thanks @thiagokokada !
I haven't had time to really put together my PR but I was playing with this code and it didn't raise your glibc issues during my tests:

      overlay =
        final: prev:
          import ./default.nix {
            poetry2nix = (poetry2nix.overlay prev final).poetry2nix;
            pkgs = prev;
            inherit (prev.stdenv.hostPlatform) system;
            rev = if (self ? rev) then self.rev else "dirty";
          };

I didn't know about nixpkgs.lib.composeManyExtensions and maybe what I'm doing is wrong but I liked the fact that it's not dependent on nixpkgs.

It means that, when only using the overlay, one can use as inputs:

    nix-alien = {
      url = "path:/home/paulg/git/nix-alien";
      inputs.nixpkgs.follows = ""; # good enough for type-check but ensure that it is not used
    };

Why I want that?
Because I then use nix-alien on many different channels for my different machines, like 21.11, 21.11-small, unstable, unstable-small... so there isn't really an obvious channel that I can put in inputs.nix-alien.inputs.nixpkgs.follows.
And if I need to set one, it means that my systems are going to pull an entire channel (thousands of files and hundreds of bytes of wear leveling at each upgrades ) just to get access to nixpkgs.lib.composeManyExtensions.

@thiagokokada
Copy link
Owner

I didn't know about nixpkgs.lib.composeManyExtensions and maybe what I'm doing is wrong but I liked the fact that it's not dependent on nixpkgs.

Well, PRs are welcome them.

@thiagokokada
Copy link
Owner

Because I then use nix-alien on many different channels for my different machines, like 21.11, 21.11-small, unstable, unstable-small

Not sure if this is really a problem. You can pin any one of them and it should work anyway.

And if I need to set one, it means that my systems are going to pull an entire channel (thousands of files and hundreds of bytes of wear leveling at each upgrades ) just to get access to nixpkgs.lib.composeManyExtensions.

It will only pull another one if you don't set inputs.nix-alien.inputs.nixpkgs.follows at all, otherwise as long you use at least one nixpkgs it can be any one of them.

@PaulGrandperrin
Copy link
Contributor Author

It will only pull another one if you don't set inputs.nix-alien.inputs.nixpkgs.follows at all, otherwise as long you use at least one nixpkgs it can be any one of them.

I'm not sure I get that. What I mean is that if I want my machines to only depend on one channel at a time, I need to do something like this:

inputs = {
    nixos-21.11.url= "...";
    nixos-21.11-small.url= "...";
    nixos-unstable.url= "...";
    nixos-unstable-small.url= "...";

    nix-alien-21.11 = {
      url = "path:/home/paulg/git/nix-alien";
      inputs.nixpkgs.follows = "nixos-21.11";
    };
    nix-alien-21.11-small = {
      url = "path:/home/paulg/git/nix-alien";
      inputs.nixpkgs.follows = "nixos-21.11-small";
    };
    nix-alien-unstable = {
      url = "path:/home/paulg/git/nix-alien";
      inputs.nixpkgs.follows = "nixos-unstable";
    };
    nix-alien-unstable-small = {
      url = "path:/home/paulg/git/nix-alien";
      inputs.nixpkgs.follows = "unstable-small";
    };
};
outputs = inputs: {
  nixosConfigurations = {
     a = { ... ; overlays = inputs.nix-alien-21.11; ...}
     b = { ... ; overlays = inputs.nix-alien-21.11-small; ...}
     c = { ... ; overlays = inputs.nix-alien-unstable; ...}
     d = { ... ; overlays = inputs.nix-alien-unstable-small; ...}
  };
}

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

No branches or pull requests

2 participants