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

Nixpkgs use 2 different fix-points with unclear separation. #10323

Closed
nbp opened this issue Oct 11, 2015 · 2 comments
Closed

Nixpkgs use 2 different fix-points with unclear separation. #10323

nbp opened this issue Oct 11, 2015 · 2 comments

Comments

@nbp
Copy link
Member

nbp commented Oct 11, 2015

While looking in nixpkgs, I noticed that we use 2 different fix-point strategy, and the difference between the 2 is not clear. #10307 highlight that there is a problem with self and pkgs are almost interchangeable but it is not clear why replacing one by the other does not work.

The problem is more than likely coming from the stdenv overrides added by the mkOverrides function. The way this function is written would cause infinite loops if we were to use pkgs instead of pkgsOrig because the name of the properties are not known ahead.

The problem here is not much about having 2 self-reference fix-points, but mostly about the fact that the first stage (pkgsOrig = pkgsFun pkgs {};) does not have a proper meaning for the 2 self-references. In the first stage, pkgs is the overloaded set of packages, while self is the non overloaded set of packages.

These 2 self-references are extremely confusing since self and pkgs are used interchangeably to lookup dependencies within all-packages.nix, either by relying on with self; or on callPackage (pkgs).

I will recommend that we convert one to the other and make them explicit within all-packages.nix, such that we can give a clear meaning to the first stage (pkgsOrig) which is used to compute the stdenv.

cc @edolstra

@Mathnerd314
Copy link
Contributor

I implemented this already in #9400, although it has a few other changes that should be split out.

@Mathnerd314
Copy link
Contributor

And now #9400 is merged, so this can be closed.

@globin globin closed this as completed Feb 27, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants