[Nix-dev] Questions about the all-packages fixpoint

Benno Fünfstück benno.fuenfstueck at gmail.com
Fri Mar 17 21:38:15 CET 2017


Hi Nicolas,

thank you for the answer, that clears up must of my questions. I do think
that `self` is pretty standard throughout nixpkgs (at least the parts that
I have worked with) for exactly this fixpoint construction, thus the name
conflict is a little unfortuntate, but seems we cannot do much about that
right now.

However, I am still unsure what you mean with

If `super.callPackage` were taking all its arguments from `super`,
then this would imply that you could not easily override the argument
of packages which are inside the dependencies of another one.
By taking the packages from `self`, we can easily replace it for all its
uses.


Well, that's why you should almost never use `super.callPackage`. I would
imagine that inside of `all-packages.nix`, at the top, we would have
something like:

`let callPackage = self.callPackage in ... `

so that all occurences of `callPackage` refer to `self.callPackage`, yet
`pkgs.callPackage` only looks inside the scope of `pkgs`. There's only one
problem I see with this, when packages take what is called `self` in
all-packages.nix directly as an argument, but I think they should take
`pkgs` instead anyway.

For me, it feels like `super.callPackage` calls something in the scope of
`super`, but perhaps that only makes more sense to me because I'm used to
it. Now that I think of it, there's an argument for `super.callPackage` to
take the deps from `self` as well: that way, `foo = super.callPackage
path/to/foo {}; ` is equavilent to `super.foo` if foo is defined like that
in `super`.

One thing that is nicer about `self.callPackage` though is that you can
follow the rule "whenever taking something from self does not lead infinite
recursion, take it from self" when writing overrides.

--
Benno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20170317/e77da42e/attachment-0001.html>


More information about the nix-dev mailing list