[Nix-dev] deepOverride (was [Nix-commits] SVN commit: nix - 22529 - raskin - in nixpkgs/trunk/pkgs: development/interpreters/perl-5.10 development/interpreters/python/2.6 development/libraries/avahi development/libraries/cairo development/libraries/consolekit development/libraries/enchant development/libraries/freetype development/libraries/libjpeg development/libraries/libxml2 development/libraries/openssl development/libraries/zlib development/tools/misc/gnum4 lib os-specific/linux/hal servers/pulseaudio tools/networking/curl top-level)

[Eelco Dolstra]

Hi,

On 07/08/2010 04:07 PM, Marc Weber wrote:

[deepOverride]
>   - propose something else (which is probably more complicated. If it
>     wasn't he'd comitted it that way)

Okay, here is another approach to deepOverride.  Take the "pan" attribute in
all-packages.nix:

  pan = import ../applications/networking/newsreaders/pan {
    inherit fetchurl stdenv pkgconfig perl pcre gettext;
    inherit (gtkLibs) gtk;
    gmime = gmime_2_2;
    spellChecking = false;
  };

Suppose we want to build Pan and its dependencies with GTK 2.16 instead of the
default (2.18).  To do this, we just call all-packages.nix with an override that
sets gtkLibs to gtkLibs216:

  pan_with_gtk216 =
    (pkgsFun { gtkLibs = gtkLibs216; }).pan;

And that's it.  (Note that "pkgsFun" is the function that returns the
all-packages composition given a set of overrides.)

If you want to do this in one attribute, that's also possible:

  pan =
    let pkgs = pkgsFun { gtkLibs = gtkLibs216; }; in
    import ../applications/networking/newsreaders/pan {
      inherit (pkgs) fetchurl stdenv pkgconfig perl pcre gettext;
      inherit (pkgs.gtkLibs) gtk;
      gmime = pkgs.gmime_2_2;
      spellChecking = false;
    };

Note that this doesn't rely on derivations exporting an "override" function.

I've always felt that deepOverride is the wrong approach: we call functions with
the "wrong" arguments, then use the override functions returned in derivations
to patch them into the "right" arguments.  This doesn't work if functions use a
different argument name for some dependency, and it will also fail if there is
an assertion in one of the functions that fails on the "wrong" arguments.  It's
also inefficient because it makes redundant calls to functions.

>   - create a custom branch ?
> 
> I think a reply "Please don't" should also include some hints helping
> the committer to choose one of the options listed above.

The default should be to follow the Nixpkgs coding conventions.  Otherwise we
end up with a proliferation of different styles that makes maintenance a lot
harder.  (This is already the case, but we should reduce it, not add to it.)
Especially cross-cutting changes (such as adding "..." everywhere) should be
discussed first to reach a consensus. Of course experiments on a branch are very
helpful in such discussions.

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