Have a nixpkgs overlay to avoid enumerating packages #94
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Re: lix-project/lix#989
cc @dwt @yu-re-ka
@dwt wrote in lix-project/lix#989 (comment):
Yeah, I don't think I am a fan of getting rid of it that way because it introduces a lot of churn for our users.
What about:
? where
overlayis apassthruargument.I would really like
if nixpkgs has the stomach to do it. To me that sounds like it would bring together most of the advantages of the various approaches.
I am always not sure with overlays, but my current understanding of them would have written this overlay to come from final:
Is this necessary to prevent an infinite recursion here, or is there just much more to learn about overlays?
I would have loved it and tried hard to get it in the PR I opened in nixpkgs.
Unfortunately, this cannot work in a module system configuration, observe:
A definition of overlay would be… ?
Notice
self, this refers tofinalactually here. Noticenix-review, it refers tofinal.nix-reviewtoo.But
nixpkgs.overlayswill change thefinal, therefore:final.nix-reviewwill change, therefore infinite recursion.Let's fix that:
Now, we can do:
nixpkgs.overlays = [ XXX.lixPackageSets.stable.overlay ];, whatXXX… ?!OK, let's do:
nixpkgs.overlays = [ (final: prev: prev.lixPackageSets.stable.overlay final prev) ];, this won't work becauseprevwill change as the overlay evolve!Also, notice that we used
final.lix, notself.lix, so it's not even dependent uponstableorlatest!In a module system configuration, we may want to have an option
lix.packages = pkgs.lixPackageSets.stable;, this means that we have a dependency inpkgs, if we add anixpkgs.overlays,pkgswill change, therefore thelix.packageswill change and this will infinitely recurse again.Conclusion: I cannot find a way to have an overlay defined inside Nixpkgs that can be applied efficiently in NixOS (or nix-darwin).
The only way I see to achieve this is to have a well-known path like
<nixpkgs/overlays/lix>and import it outside of the lifecycle of the module system. This doesn't even solve the "I'd like to install the right overlay for the right package set".e.g.
To solve that, we would need to make the choice of the package set a string.
By doing that, we could do:
nixpkgs.overlays = [ (import <nixpkgs/overlays/lix> { inherit (config.lix) packages; }) ];The implementation of that overlay would do
final.lixPackageSets.${packages}, so we lose the possibility to pass arbitrary package sets or extend the scope.Overall, I am not sure I can figure out an ideal solution, but I need to read Yureka's views again about this.
lix-project/lix#989 (comment) seems indeed the way forward to improve things but this requires cooperation with CppNix people.
I personally don't have the spoons for it, but I would happily help and enable anything on the Lix side to make this happen.
Yeah, I think I slowly understand why @yu-re-ka made the suggestion she did. How would it look if we incrementally worked in that direction? Would we start with
config.lix.packageSetand then later rename that toconfig.nix.packageSet?My naive view is that this should not involve collaboration of cppnix, as this is all happening in nixpkgs? When we move to
config.nix.packageSetwe would need some forwards to be in place, but that shouldn't be a big deal?The problem is that users are always going to attempt using the pkgs.colmena / pkgs.nix-review / ... from the all-packages package set first, and they will not get the version built against their chosen Nix/Lix version.
Without removing the packages from all-packages, we really don't get any benefit over the current state (where users can already spell out pkgs.lixPackageSets.latest.<package>).
Otherwise it could still be implemented in steps though:
callPackagecalls (instead of overriding the packages from all-packages, since we ultimately want to remove them)At any point in between: Introduce a NixOS / nix-darwin option used to reference the user-chosen Nix/Lix packageSet