|
From: | Philip McGrath |
Subject: | [bug#51838] [PATCH v6 05/41] guix: node-build-system: Add 'delete-dependencies' helper function. |
Date: | Wed, 5 Jan 2022 14:08:30 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |