[Nix-dev] Re: args: with args

[Michael Raskin]

Eelco Dolstra wrote:
> I agree.  The "args; with args" construct basically says "this function 
> takes an arbitrary set of arguments, some of which may or may not be 
> used".  So you don't get error messages about missing arguments where 
> you might expect them (at call time).  And unnecessary arguments aren't 
> flagged at all.

 > Another downside to "with" is that it completely makes it impossible
 > to determine whether there are undefined variables in an expression. 
  > So statically checking Nix expressions for mistyped variable names
 > becomes impossible (at least under the "withs").

I sometimes even abuse the property about redundant arguments to make 
overriding phases easier (I mean overriding from caller).

And unused variables are not reported when you really need it anyway - 
with traditional style I often add something to arguments and to 
declaration but never actually use it. Takes some time to even recognize 
something is wrong (if it is a non-critical dependency).

About error reporting: you get stack trace anyway.

And is "args: ({some,thing,stdenv}: stdenv.mkDerivation{}) args; "
more acceptable for you? It will give statical verification, though it 
will make external overrides add some code to callee. I will generate 
buildInputs etc from args member list then.

I just have less problems debugging problems you mentioned (that surface 
  on their own) than checking that no difference between three copies of 
one list exist.

> Re builderDefs: I think the idea is to make the stdenv setup script 
> modular so that changes in one small part don't trigger rebuilds of 
> everything.  However whether this is actually worth it is questionable 
> (a change to the "doConfigure" phase will still rebuild pretty much 
> everything, and you can override the stdenv setup script on a 
> per-package basis anyway).  And certainly writing
You can make change to doConfigure conditional. Example I probably 
already cited: we will add LZMA support to unpackPhase. Options with 
traditional approach are:
1. Rebuild everything, including things not depending on any single 
unpacking LZMA for build.
1a. The same, but wait for some needed anyway gcc/glibc update. Takes 
some time.
2. Fork setup.sh one more time. I remember that last time it was done, 
setup-new-2.sh was already considered a bit too much.
3. Add support as a separate script/code snippet and include it from 
every expression using LZMA. I bet someone will write another version 
just because it is easy to forget that support already exists.

Note that doUnpack is used by next-to-every expression, yet adding some 
new unpack method is not triggering full rebuild in builderDefs.

> 
>   builder = writeScript (name + "-builder")
>     (textClosure localDefs [doConfigure doMakeInstall doForceShare 
> doPropagate]);
> 
> for every package is not very appealing.
I would object to the word "writing". I ask to use correct term editing, 
because whatever style you use, templates save a lot of typing, so it is 
strange not to use them. And I would say that the intent is quite 
straightforward.