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

[Philip McGrath <philip@philipmcgrath.com>]

Hi,

On 12/30/21 21:46, Liliana Marie Prikler wrote:
> Am Donnerstag, dem 30.12.2021 um 20:09 -0500 schrieb Philip McGrath:
>> I still feel that there's something I'm fundamentally not
>> understanding about your objections to '#:make-absent-dependencies',
>> which is why, in v6, I tried to do exactly as you had proposed:
>>
>> On 12/20/21 17:00, Liliana Marie Prikler wrote:
>>   > Hi Timothy,
>>   >
>>   > Am Montag, dem 20.12.2021 um 15:15 -0500 schrieb Timothy Sample:
>>   >> Hi Philip,
>>   >>
>>   >> Philip McGrath <philip@philipmcgrath.com> writes:
>>   >>
>>   >>> If we took your final suggestion above, I think we'd have
>> something
>>   >>> like this:
>>   >>>
>>   >>> ```
>>   >>> #:phases
>>   >>> (modify-phases %standard-phases
>>   >>>    (add-after 'unpack 'delete-dependencies
>>   >>>      (make-delete-dependencies-phase '("node-tap"))))
>>   >>> ```
>>   >>
>>   >> I’m perfectly happy with this if it’s a compromise we all can
>> agree on.
>>   >> It is exactly what popped into my imagination when I read
>> Liliana’s
>>   >> suggestion.  I guess the one thing missing is that it would not
>>   >> necessarily be implemented on top of better “package.json”
>>   >> manipulation support.  That said, it doesn’t preclude providing
>> that
>>   >> support if/when the need arises.
>>   > In my personal opinion, we would write that support first and
>> perhaps
>>   > the shorthands later.  I.e.
>>   >
>>   > (add-after 'patch-dependencies 'drop-junk
>>   >    (lambda _
>>   >      (with-atomic-json-replacement "package.json"
>>   >        (lambda (json) (delete-dependencies json '("node-tap"))))))
> To be fair, finding the right sweet spot between being overly verbose
> and code golfing is difficult.

I will admit that I am more than a little frustrated that, having put 
aside my own reservations and implemented the compromise proposal it 
seemed everyone could live with, it now seems that the consensus was in 
fact illusory. Moreover, I still do not understand what specific changes 
I could send in a v8 that would get this patch series to a state where 
everyone would agree it could be applied.

> 
>> Certainly I do agree that it would be better to support code more
>> concise than that! But I think all of these variations are strictly
>> worse than '#:absent-dependencies'. It isn't just that they are more
>> typing: the require authors of package definitions to have some (not
>> very much, but some) procedural knowledge about _how_ 'node-build-
>> system' deals with the absence of dependencies, rather
>> than with '#:absent-dependencies', declaratively specifying _what_ is
>> to be done.
> Understanding build systems is for nerds.  We here at leftpad.org care
> about the things that are really important.
> 

I don't know what to make of this comment, and I especially don't 
understand what the notorious left-pad incident has to do with my views. 
Aside from its inflammatory nature, I think left-pad is a confusing way 
to make a point because many people have tried to make it "stand for" 
many different, perhaps even mutually contradictory, conclusions.

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.

We use './configure && make && make install' to avoid having to know 
about the intricacies of flags for gcc, ordering requirements for 
building sub-projects, and innumerable quirks of strange and venerable 
systems that Autotools supports so that most of us can ignore them. We 
use 'gnu-build-system' to avoid having to know, and constantly repeat, 
the details of invoking 'configure' and 'make' to find Guix inputs and 
build to Guix outputs, along with further details of what files need to 
be patched when. Sometimes we nonetheless need to drop down to a lower 
level of abstraction, and Guix makes it convenient to do so, but the 
goal is to provide useful abstractions.

For a personal example, I've never written so much as "Hello, world" in 
Go, but I've been able to contribute packages to Guix for software I use 
that happens to be written in Go, which was much easier to do because 
'go-build-system' offers useful high-level abstractions like 
'#:unpack-path' and '#:import-path'. I didn't need to know _how_ 
'go-build-system' arranges the build environment based on those values, 
or even anything beyond the most superficial understanding of _what_ 
those values are, in order to build a Go package.

>> which would have avoided my earlier reservations about making the
>> JSON representation part of the build system's public API for the
>> first time.
>>
>> So I'm not feeling very confident in my ability to predict what
>> changes would or would not block consensus.
> Adding a gratuitous keyword is an immediate blocker as we've discussed
> at length ;)

Even when I have disagreed with your point of view, I have been trying 
my best to understand it, and I don't doubt that it is offered in good 
faith. 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.

I don't want to speak for anyone but myself, but I haven't heard anyone 
else share these objections. And again, I also agreed to v6 of this 
series, in which I removed the keyword.

I don't have time right now to go through the latest comments point by 
point: I will try to do so later. From my perspective, though, the 
substance of these patches has been ready to go for something like six 
weeks now, and the few enhancements since then could easily have been 
small follow-on patches. I would consider it very regrettable if this 
patch series were to continue to be blocked by stylistic considerations 
in the implementation of unexported helper functions.

-Philip