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

[Liliana Marie Prikler]

Hi,

Am Freitag, dem 07.01.2022 um 23:14 -0500 schrieb Philip McGrath:
> I do intend to propose  '#:absent-dependencies' immediately
> thereafter.
And I do intend to reject that proposal immediately thereafter. 
Nothing personal, but I think I've made a clear enough case against it,
although I could go into even more detail if you want me to.

> 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'.
The reason to e.g. use #:tests? over (delete 'check) is not because the
code looks nicer (although it does).  As Jelle pointed out, code that
does ugly things should be allowed to look ugly, and in terms of node-
build-system needing to delete dependencies *at all* is already an ugly
thing.  There's no need for a convenience keyword, much less a reason
to implement one for the sake of nicer-looking code.

> 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. 
The word absent is not neutral.  It implies it's not there when it
should be.  My use of unwanted does the opposite.  It implies it should
not be there when upstream claims it should.  The obvious middle ground
is good old "exclude", but I think it'd be hard to make an argument
even for #:excluded-dependencies.

> 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". 
You just substituted missing for another spelling of it.  That doesn't
really help here.

> 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? 
It would mean committing the error of specifying a dependency both as
input and as absent.  This is for the lack of a better word UB.


> 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.
Even then, much of our other discussion revolves around the question of
what the implications of those are.  If we, the experts, can't be
trusted to have a clear enough understanding, how should we trust non-
expert users on the matter?  That's why I wanted to encode the
dependency key in delete-dependencies.  That way, one could specify
"delete X from dependencies after it was introduced by Guix" or "no, I
really don't want it to be a peer dependency either".  And until we
have a clearer image, we could accept both forms and see what problems
they'd cause later on, then reject one in favour of the other by
patching them out over time.

None of that would be possible with a keyword, at least one with a nice
value encoding.  You either change all node packages at a time,
potentially causing a c-u-worthy rebuild, or you don't and you're
stuck.

Cheers