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
_______________________________________________
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
