Add new top-level package set for headless packages #29283
Conversation
|
@copumpkin, thanks for your PR! By analyzing the history of the files in this pull request, we identified @edolstra, @7c6f434c and @k0ral to be potential reviewers. |
The package set itself is currnetly fairly small and taken from the no-x-libs.nix module that we already had.
copumpkin
force-pushed
the
nearly-headless-nix
branch
from
6307e11 to
9761ecc
Compare
| ### OVERLAYS (n.b.: don't add to these without consulting the community; they can be expensive) | ||
|
|
||
| headless-overlay = import ./headless.nix; | ||
| headless = lib.lowPrioSet (recurseIntoAttrs (import path { overlays = [ headless-overlay ]; })); |
There was a problem hiding this comment.
Won't this disregard any overlays and config the user chose to apply? Would it be possible to determine what Nixpkgs was initially called with, and use that here?
There was a problem hiding this comment.
I could probably merge it with the parameter set passed into nixpkgs?
There was a problem hiding this comment.
Merging it is proving rather ugly, since the stuff I can pass in at the top level isn't what I get inside all-packages.nix anymore. @Ericson2314 any ideas? I want to be able to put @args by the argument list at the top of all-packages.nix and then import pkgs.path (args // overlay-junk) but they don't match up.
There was a problem hiding this comment.
all-packages.nix is just for a single stage of nixpkgs and therefore shouldn't import the whole thing.
But.... it does still do that in a few more places, and for this purpose I defined nixpkgsFun and passed it in. You might still clobber other overlays, but that can be dealt with in time.
See https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/default.nix#L66-L83
There was a problem hiding this comment.
If nothing in all-packages.nix is going to use headless, I don't think we should put it in there. We should have a different file for "example nixpkgs instantations"---release-lib.nix and release-cross.nix could use it, for example. lib/platforms/examples.nix is somewhat similar.
There was a problem hiding this comment.
@copumpkin A different file; one not accessible from import <nixpkgs> {}.
There was a problem hiding this comment.
But then usability is shot, right? I have someone on twitter saying "oh awesome, I can use headless packages? How do I just switch to using those?" I want it to be easy to get headless packages that you don't have to compile by hand.
I also don't see (outside of some notional "purity" argument) a fundamental reason to leave it out of all-packages. If our entry-point weren't all-packages.nix, in an ideal world, I wouldn't put it there, but that's how everyone gets into nixpkgs nowadays and I don't want it to be painful to get things like this, just because it isn't strictly a "package". There's so much crap in all-packages.nix today and drawing the line here without a pleasant alternative feels very theoretical at the cost of usability.
There was a problem hiding this comment.
It feels like perhaps something between impure.nix and all-packages.nix could include both this and all-packages.nix, as well as other things like "NixOS VM images" and other stuff that is painful to get at today.
There was a problem hiding this comment.
@copumpkin elaborating and improving on what I said on IRC.
-
There should be a canonical location to import all such overlays (and maybe other non-pkg-set-depending expressions). That way something like
(import <nixpkgs/pkgs/overlays>).fooBarworks and is cheap. -
We can, for discoverability, make that (i.e
pkgs/overlays/default.nixor whatever ends up being) accessible fromimport <nixpkgs> {}.pkgs/top-level/default.nixis betweenpkgs/top-level/impure.nixandpkgs/top-level/stage.nixas you and I both like, and indeed would be a good spot to splice it in.
There was a problem hiding this comment.
@copumpkin I relented for now with #42874
|
Branch name 👻 ... I didn't know there were more Nicks. My script didn't detect this triggering any new Hydra builds at all, but it might be buggy (the script). |
|
What do you all think about https://github.com/NixOS/nixpkgs/pull/29283/files#r138730857 ? I'd use a very similar approach for providing example nixpkgs instantiations for cross compilation, which many of you had asked for. The key is to (edit relented in #42874) |
veprbl
added
the
2.status: merge conflict
|
Are there any updates on this pull request, please? |
|
Thank you for your contributions.
|
stale
bot
added
the
2.status: stale
ryantm
added
2.status: merge conflict
|
Closing this as it is abandoned. |
The package set itself is currnetly fairly small and taken from the no-x-libs.nix module that we already had.
Should address #29135. Ideally I'd prefer to move towards something more like #12877 but that seemed like a much bigger bite, and this could always move to using that once implemented.
cc @edolstra @vcunat
P.S: I'm feeling pretty good about the branch name I picked. Anyone enjoy Harry Potter?