[Nix-dev] Re: warning if trying to install a package but it fails an assert.

[Marc Weber]

On Fri, Dec 19, 2008 at 07:45:53PM +0300, Michael Raskin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Marc Weber wrote:
> > real life. I'd vote for composableDerivation..
> 
> 1. You are biased.
> 2. We would better define interface first, not the implementation.
> 
> >     libXDefaultOptsAndFun = {
> >       fun = opts : stdenv.mkDerivation { ... };
> >       defaultOpts = { .. };
> >     };
> >     X= libXDefaultOptsAndFun.fun libXDefaultOptsAndFun.defaultOpts;
> > 
> > 
> >     prog = import .. {
> >       inherit libXDefaultOptsAndFun;
> >     };
> 
> Is it me or is it not more complicated than composableDerivation approach?
> 
> >     libX = composableDerivation {
> >       initial = {
> >         # default stuff you pass to composableDerivation 
> >         flags = { x = .. };
> >         cfg = { xSupport = true;  };
> >       };
> >     };
> > 
> >     prog = import .. {
> >       libX
> >     }
> > 
> >     ========== prog.nix ==================
> >     args; with args;
> >     stdenv.mkDerivation {
> >       ...
> >       buildInputs = [ libY (libX.passthru.funChangeConfig { xSupport = false ;  })];
> >       ...
> >     }
> 
> Well, looks like overkill for the most common case without being a
> silver bullet for theoretically supporting large changes while still
> using everything still useful from default configuration.
Where is the difference? The difference is that I've put all
configuration options into a separate attr set called flags. The reason
for doing so was introspection.. if you have mixed the configuration
values (true / false) and the default attr names (name, meta,
buildInputs).. you no longer have a chance to get a list of
configuration options to expose them to a gui later on.. (Don't know
whether someone will ever write one..). Maybe I shouldn't have added yet
another *magic* function without any code called funChangeConfig. The
only thing it should do is modify the argument to look like { cfg = args; }.


> > Note that a libY can be passed without applying options. This is the
> > common case. Changing options is the exception, isn't it?
> If you still have a check, what's the point?
About which check are you talking now?

> Note that in that case we can omit checks - xSupport stays untouched. Of
> course, there are some corner cases. composedArgsAndFun still allows to
> override everything, but it can become tricky no matter how do you do it.
I've lost you. Which checks ? Are you talking about the subversion perl
support assertion? I'd still vote for having those because if you don't
use defaults you still don't want to go hunting for non expected
behaviour..

Marc Weber