Hello,
Philip McGrath <philip@philipmcgrath.com> writes:
On 11/20/21 02:41, Liliana Marie Prikler wrote:
In the resolve-dependencies subprocedure, we could check whether we
have a matching input somewhere and only include the dependency if we
do. WDYT?
[...]
The other issue is that deleting packages with no matching input by
default would replicate some of the drawbacks of the current `(delete
'configure)` approach. I think it's better to have an explicit list of
dependencies that Guix is deleting. If eventually we package all of
the missing dependencies for Guix, it would be much easier to find the
packages that ought to use it. And, in the highly dynamic JavaScript
world, I'm reluctant to give up one of the few static checks we
have. If a missing package that really was required were automatically
deleted from "package.json", it seems the failure mode would by a
mysterious runtime error, potentially many steps down a dependency
chain.
This is well put. I actually experimented with a similar approach when
we updated the Node.js build system. This is a big improvement over
deleting the configure phase, which would never scale to more than a
handful of packages. Having a build-time check that ensures all the
developer-declared dependencies are available (save the “absent” ones)
will be very helpful when we are maintaining hundreds of JavaScript
packages. :)
For the patch itself, it would be better to move a lot of your commit
message into a comment somewhere in the build system code. If we had a
section in the manual for Node packages, it would go there, but alas....
I think most people would be happy to see a comment in the build system
code and be saved from having to poke around with ‘git blame’.