[bug#51838] [PATCH v5 07/45] guix: node-build-system: Add #:absent-dependencies argument.

[Timothy Sample]

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> For the GNU build system (and likewise meson-build-system), the default
> behaviour if you haven't specified anything as per upstream conventions
> is typically to error if the package is required and omit it if it's
> not.  The default behaviour of node-build-system (and likewise cargo
> and most other build systems that come with the advertisement of "we
> know package managers better than people who actually produce useful
> package managers) is "Oh my god, you don't have an exact copy of the
> machine that built this stuff locally, I am going to barf huge walls of
> noise at you".  Therefore, we can't meaningfully compare those build
> systems in terms of strategies.

NPM packages tend to wildly over-specify their dependencies.  We already
remove dependency version checking, and before this change, many of our
packages skipped any kind of dependency checking by skipping the
configure phase altogether.  To me, the ‘#:absent-dependencies’ approach
tries to work around the dependency over-specification by listing
exactly those things that are only there to elicit a useless “Oh my god
[...], I’m going to barf huge walls of noise” message.  The rest of the
dependencies are those that the Guix package author deemed required (or
at least important).  Basically, ‘#:absent-dependencies’ helps us
translate between the NPM culture of over-specification (which is really
a culture of prioritizing package author over package user) and the GNU
culture of “DWIM” dependencies.

> If we really want some static verification for node-build-system, I
> think we should take that as an approach rather than hard-coding
> (absent) dependencies literally everywhere.

We need some way to know what to statically verify.  We can’t magically
know what’s important and what isn’t.  The two options in this thread
are ‘#:absent-dependencies’, and only checking what’s already in the
package’s inputs.  What worries me about the second approach is that it
offers no help when updating a package.  With ‘#:absent-dependencies’,
if the developer adds a new dependency that really is required, we will
get a build-time failure letting us know.  Whoever is updating the
package can fix it before even committing anything.  If we just check
the inputs, that’s not the case, and we might end up with Philip’s
“mysterious runtime error, potentially many steps down a dependency
chain.”  Hopefully tests would catch it, but I like the extra assurance.

Another benefit is that it would help us gain knowledge as to which NPM
packages are often used but not actually required (e.g., NPM publishing
tools).  With this knowledge, we could write a clever NPM importer that
ignored obviously inessential dependencies.

I guess I’m starting to sound like a broken record now – this is
basically what we covered before!  :)  Maybe we’re in need of a fresh
perspective.  (If anyone is reading along and has thoughts, feel free to
chime in!)


-- Tim