[bug#51838] [PATCH v6 05/41] guix: node-build-system: Add 'delete-dependencies' helper function.

[Philip McGrath]

Hi,

On 1/5/22 16:04, Liliana Marie Prikler wrote:
> Am Mittwoch, dem 05.01.2022 um 14:08 -0500 schrieb Philip McGrath:
> > In case it helps at all to state my position more fully: with or
> > without Guix, I think a major purpose, perhaps even the primary
> > purpose, of _any_ build system is to relieve users (including
> > ourselves) of the cognitive burden of lower-level details. Build
> > systems are a means of abstraction and encapsulation.
> >
> > [...]
> I agree with you that abstractions ought to help, but we do have some
> disagreements about the amount by which certain abstractions help.
> Those are gut feeling value judgements, they're not all entirely
> rational.
>
> > I hope this is just a matter of some nuance in the connotation of
> > the word "gratuitous" not coming across properly, but I would
> > appreciate the same consideration being extended to my perspective.
> >
> > Almost tautologically, I don't think adding '#:absent-dependencies'
> > would be gratuitous, or I wouldn't have proposed it.
> Generally, keywords are reserved for a few special operations.  I don't
> currently have the time to write them all up, but suffice it to say I
> don't believe the way #:absent-dependencies would be used fits into any
> of those.  I can write that up in a later message if you feel it's
> imporant enough.

It isn't needed right now, since we've agreed to go ahead without 
'#:absent-dependencies', but, since I do intend to propose 
'#:absent-dependencies' immediately thereafter, I think it would be 
useful: this seems to get close to the core of the disagreement we've 
been having for the last ... couple months?

I don't see a reason why we should hesitate to use keywords when they 
enable especially nice code. Actually, I've sometimes wished build 
systems would '#:allow-other-keys'.

I'd expect '#:absent-dependencies' to be more common for 
'node-build-system' packages than '#:tests?', since I'd expect almost 
every package that would use '#:tests? #f', plus a significant number 
that wouldn't, to use '#:absent-dependencies'.

Jumping back to an earlier email:

On 12/30/21 21:46, Liliana Marie Prikler wrote:
> Am Donnerstag, dem 30.12.2021 um 20:09 -0500 schrieb Philip McGrath:
>> In my view, the high-level purpose of 'delete-dependencies',
>> '#:absent-dependencies', or whatever is to gather our collective
>> procedural knowledge about how to modify a "package.json" file to
>> build a package without some of the dependencies its developers have
>> declared and to encode that knowledge in a single, abstracted point
>> of control in 'node-build-system', so that authors of Node.js package
>> definitions can simply specify which declared dependencies are absent
>> and leave it to 'node-build-system' to act accordingly. (I don't
>> think it matters _why_ the dependencies are absent, i.e. whether we
>> don't want the them or merely don't have them.)
> For the record, you can delete present dependencies as well, which is
> one shortcoming in the "absent dependencies" metaphor.
[...]

>> It is unnecessarily flexible because, if a package author ever passes
>> some other value for '#:json-keys', that would seem to indicate that
>> there's some procedural knowledge missing from 'node-build-system',
>> and it should be added there.
> The reason I have it as such is that a packager might decide in the
> future to e.g. only drop a peer dependency, that might share a name
> with a dev dependency or something along those lines.

Since I don't think I've written it down before, my hope in describing 
them as "absent" dependencies was to state that they are absent from the 
build environment, while being as neutral as I could about _why_ they 
might be absent. In particular, I wanted to avoid the implications of 
"missing", which can have implications of "we don't know where X is" and 
"it would be better if we found X". One day, it would probably be nice 
to have 'node-aws-sdk' packaged for Guix, but, even if we knew the 
precise line number in "node-xyz.scm" where it we could find its 
definition, we would not want to use it while building 'node-sqlite3'.

So, having established that the adjectives are a little fuzzy, I don't 
understand what it would mean to "delete present dependencies". If they 
are present in the build environment, why delete them? If the issue is 
that they only are needed at build time, the 'install' phase of 
'node-build-system' should already handle this by passing '--production' 
to 'npm install'.

If a "peerDependency" and a "devDependency" share a name, then they 
refer to the same package. I believe it would be an error (logically, 
that is: I do know npm would not raise an exception) to have a 
"peerDependency" that is also a "devDependency" or a "dependency": as I 
understand it (poorly!), peer dependencies are meant to be some weaker 
kind of relationship.

But again, none of this needs to stand in the way of merging this patch 
series.

-Philip