-
-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
top-level: Preserve config and other arguments when recurring, while preventing information leak #19940
Conversation
@Ericson2314, thanks for your PR! By analyzing the history of the files in this pull request, we identified @nbp to be a potential reviewer. |
cc @nbp |
@Ericson2314 we have to be careful here to also have in mind upcoming changes for security updates, so if you're changing top-level stuff also cc Nicolas |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As long as it doesn't interfere with @nbp's work it looks good
Thanks for CCing me, @Ericson2314! I approve of this pull request for the reasons that @Ericson2314 listed and also because it gets rid of the mutually recursive imports between As far as I can tell, the pull request is good to merge right now, except for what I think is a minor regression. It looks like you are forgetting to pass
I also have some comments that I think would improve the pull request but shouldn't prevent it from being merged: I think that This is just my personal taste, but I think the 9-line comment in |
@DavidEGrayson Thanks for the review and enthusiasm!
Huh? That file doesn't use it.
It is slightly faster to not rebuild pkgs. Later in my original PR, I remove the need for
After I'm all done rewriting this stuff, I plan on making a new manual section "tying nixpkgs together" or something like that. I'll probably move/rewrite the comment there then. |
Oh ok, never mind about |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These changes looks good, except for the removal of the topLevelArguments
set, and the trivialBuilders
, stdenvDefault
, allPackages
modifications.
|
||
stdenvDefault = self: super: (import ./stdenv.nix topLevelArguments) {} pkgs; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What the hell is pkgs doing here?!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its been there all along, but I remove it in this PR a follow up PR. See https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/default.nix#L74 and your original ad31783 .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, the old version was very confusing, passing pkgs
in as an argument and naming the argument super
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using pkgs
here, whatever it is named is a terrible choice, as stdenvCross
which depends on it rely on the fix-point result and can cause much more trouble. I would prefer if we could replace this pkgs
by either self
or super
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea is
- final normal phase: build = host = target
- cross compiler phase: build = host != target
- final cross packages phase: build != host = target
The current stuff is broken because it divvies up 2 arbitrarily between 1 and 3.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nbp So yeah, my hope is to get this one merged as is, as multiple people have reviewed it positively, and your only complaint is procedural. Then the next one sets up cross-compiling correctly, but its probably still broken in practice (it's subtly broken already). Finally using @DavidEGrayson's and @vcunat's good work atop my foundation, we can actually fix cross-compiling.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, in my pull request (#18386), in top-level/stdenv.nix
, if crossSystem
is not null, then I make the final stdenv using the default stdenv like this:
(mkPackages { bootStdenv = defaultStdenv; }).stdenvCross
So I think that's what @Ericson2314 means when he says there will be another level of bootstrapping. So ultimately stdenv.nix does not need to use pkgs
, but it will need mkPackages
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@DavidEGrayson What you say is true. But I'd like to do more things with that extra phase as well. In my (currently out of date) rebase of @vcunat's work, in that same phase I also build the cross tools Ericson2314@ee2a484#diff-1640a202e3ce4fd5a204d6c39e252787R110, not just stdenvCross
. Then those get simply included in stdenvCross
without needing to force-native or anything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current .nativeDrv
.crossDrv
is IMO a weird hack trying to fake an extra phases.
@zimbatm , Even if they are a few issues, these should be easy to merge. |
1eb0a47
to
22aeda0
Compare
@nbp it would be nice to hear why you don't like the other changes. For me they are all related--with |
@Ericson2314 That's not that I don't like them, but more that they are not related to this pull request. |
@nbp ...Can I rename the pull request then? Also more seriously travis correct found a real bug. The package in all-packages that now uses |
22aeda0
to
a1b870a
Compare
Fixed cross compiling, and addressed the description the full scope of this PR including why I see the changes as all being related. |
f4cb25e
to
88ecfaa
Compare
88ecfaa
to
09198c5
Compare
Great! I will make a new pull request to put my cross-compiling fixes on top of this. |
@DavidEGrayson err hold up if you don't mind. My cleanups got moved to other PR for @nbp. |
Okay, sounds good. |
Cleanup commit #20108 |
Current there is a few times that nixpkgs recurs, and when it does config/etc is discarded which seems...wrong. Additionally, we take advantage of the separation of the pure and impure generation of default nixpkgs arguments: only the pure generation is repeated on recur.
At the same time, this means that
all-packages.nix
andstdenv.nix
need not more but less arguments, because some were just used when recurring andmkPackages
will close over those instead. This prevents people from accidentally inspecting those arguments complicating the fixpoint. [mkPackages
should have a bad smell, we don't the same things to happen without the odor.]This is part of my #15043, and also part of #18386
This entire patch is fairly small, but is again broken up into puny commits for easy reviewing.
CC @DavidEGrayson because the patch overlaps with your first commit
CC @zimbatm because you've helped me merge that PR piece-by-piece before :D