[Nix-dev] Re: [Nix-commits] SVN commit: nix - 18466 - eelco - in nixpkgs/trunk/pkgs: build-support/vm lib

[Eelco Dolstra]

Hi,

Lluís Batlle wrote:

> The usage of overrideDerivation with the
> super-stdenv-allowing-cross-compilation may be a bit confusing. The
> final "buildInputs" and "buildNativeInputs" finally used as parameters
> for the "derivation" are changed from those passed to "mkDerivation",
> according to the cross or native compilation.

Yes.  In general, it's better to use pkg.override { ... }, since this overrides
the arguments to the exposed interface of the package function.

As the comment says, overrideDerivation is mostly for "ad-hoc" customisation,
where you want to quickly hack something on top of some package function.  In
that role, it should not be used in Nixpkgs itself, but in
~/.nixpkgs/confix.nix.  It's mostly to get rid of highly (user-)specific
customisations.  For instance, Marc once added arguments named "patches" and
"nameSuffix" to tools/package-management/nix/unstable.nix, which aren't used
anywhere in Nixpkgs or NixOS.  These are ad-hoc, because you might as well add
"preConfigure", "postInstall", and a dozen other customisation arguments - to
every package in Nixpkgs, because somebody might conceivably need them :-)

> overrideDerivation should be used attenting on what play is done in
> the attributes passed to mkDerivation, and how they map to the
> attributes passed to derivation. And even for a simpler example,
> imagine a user wrote a unpackPhase relying on "${src}" instead of
> "$src"... then overriding the src through overrideDerivation would not
> change the unpackPhase. Right?

Yes, exactly.  It breaks abstraction.

The other application of overrideDerivation is as a meta-operation to transform
a derivation, like running it in a virtual machine.  This doesn't have the
abstraction problem.

-- 
Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/