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.
_______________________________________________
nix-dev mailing list
[email protected]
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
