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

Add new top-level package set for headless packages #29283

Closed
wants to merge 1 commit into from

Conversation

copumpkin
Copy link
Member

@copumpkin copumpkin commented Sep 12, 2017

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?

@mention-bot
Copy link

@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.
### 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 ]; }));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could probably merge it with the parameter set passed into nixpkgs?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@copumpkin A different file; one not accessible from import <nixpkgs> {}.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@copumpkin elaborating and improving on what I said on IRC.

  1. 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>).fooBar works and is cheap.

  2. We can, for discoverability, make that (i.e pkgs/overlays/default.nix or whatever ends up being) accessible from import <nixpkgs> {}. pkgs/top-level/default.nix is between pkgs/top-level/impure.nix and pkgs/top-level/stage.nix as you and I both like, and indeed would be a good spot to splice it in.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@copumpkin I relented for now with #42874

@vcunat
Copy link
Member

vcunat commented Sep 13, 2017

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

@Ericson2314
Copy link
Member

Ericson2314 commented Nov 5, 2017

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 // it in, not use the fixed point, because we don't want other packages depending on these "demo imports".

(edit relented in #42874)

@mmahut
Copy link
Member

mmahut commented Aug 12, 2019

Are there any updates on this pull request, please?

@stale
Copy link

stale bot commented Jun 1, 2020

Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:

  1. Search for maintainers and people that previously touched the
    related code and @ mention them in a comment.
  2. Ask on the NixOS Discourse. 3. Ask on the #nixos channel on
    irc.freenode.net.

@stale stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jun 1, 2020
@lucasew
Copy link
Contributor

lucasew commented Aug 24, 2022

Closing this as it is abandoned.

@lucasew lucasew closed this Aug 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2.status: merge conflict 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

10 participants