[Nix-dev] Re: warning if trying to install a package but it fails an assert.
Ludovic Courtès
ludo at gnu.org
Fri Dec 19 18:42:27 CET 2008
Marc Weber <marco-oweber at gmx.de> writes:
> On Fri, Dec 19, 2008 at 02:09:06PM +0100, Ludovic Courtès wrote:
>> How would you achieve that? In the example of Git, does that mean you
>> would pass to the Git expression both a `makeSubversion' function *and*
>> a "default" `subversion' derivation?
> You got it: That's what all the *AndFun stuff is about (initial idea by
> Michael Raskin). Simplified it looks like this and I feel its the best
> thing we have at the moment to solve these issues:
>
> let defaultArgs = { name= "x"; buildInputs = [ .. ]; meta = ..; }; in
>
> derivation = mkDerivationX (
> defaultArgs // {
> passthru = { fun = overrides : mkDerivationX (defaultArgs // overrides); };
> })
Well, have asMuchFun as you want, but that's no fun to me.
Really, I don't get the point. I'm under the impression that the
machinery is very complex for little gain.
"Andres Loeh" <andres.loeh at googlemail.com>
writes:
> Yes, I agree that the default for subversion should be *with*
> perl bindings.
Yes, and we can surely do the same for similar cases where the potential
for duplication arises.
> Currently, we're mostly passing complete derivations (let's say,
> because I like types, of type DERIVATION) into the Nix
> expressions for individual packages. These have a fixed set of
> options hard-wired at the time they're passed. Instead of doing
> that, let's pass the actual function, of type
> (OPTIONS -> DERIVATION) plus a set of default options (of type
> OPTIONS). The individual package can then decide whether to just
> go with the default options (by applying the function to the
> options), or if to modify the options before applying.
Thanks for the explanation.
Again, it looks overly complex to me. I'm pretty sure we can avoid
duplication in most cases by choosing reasonable defaults. Do you have
use cases in mind where this approach is a must?
Thanks,
Ludo'.
More information about the nix-dev
mailing list