From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 4JgSAR3t1WHrCwAAgWs5BA (envelope-from ) for ; Wed, 05 Jan 2022 20:10:21 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id gJchOhzt1WFaZwEA9RJhRA (envelope-from ) for ; Wed, 05 Jan 2022 20:10:20 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 7BA002C0B3 for ; Wed, 5 Jan 2022 20:10:20 +0100 (CET) Received: from localhost ([::1]:46162 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n5Bfv-0006Qa-1U for larch@yhetil.org; Wed, 05 Jan 2022 14:10:19 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52898) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n5Beg-0005sv-Cn for guix-patches@gnu.org; Wed, 05 Jan 2022 14:09:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:58524) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n5Beg-0003aN-2Y for guix-patches@gnu.org; Wed, 05 Jan 2022 14:09:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n5Bef-0002uk-UL for guix-patches@gnu.org; Wed, 05 Jan 2022 14:09:01 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#51838] [PATCH v6 05/41] guix: node-build-system: Add 'delete-dependencies' helper function. Resent-From: Philip McGrath Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Wed, 05 Jan 2022 19:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51838 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Liliana Marie Prikler , 51838@debbugs.gnu.org Cc: Timothy Sample , Pierre Langlois , Jelle Licht Received: via spool by 51838-submit@debbugs.gnu.org id=B51838.164140972011170 (code B ref 51838); Wed, 05 Jan 2022 19:09:01 +0000 Received: (at 51838) by debbugs.gnu.org; 5 Jan 2022 19:08:40 +0000 Received: from localhost ([127.0.0.1]:41837 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n5BeJ-0002u6-MO for submit@debbugs.gnu.org; Wed, 05 Jan 2022 14:08:40 -0500 Received: from mail-qt1-f169.google.com ([209.85.160.169]:41474) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n5BeH-0002tq-GO for 51838@debbugs.gnu.org; Wed, 05 Jan 2022 14:08:38 -0500 Received: by mail-qt1-f169.google.com with SMTP id v22so38465127qtx.8 for <51838@debbugs.gnu.org>; Wed, 05 Jan 2022 11:08:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=philipmcgrath.com; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=3lMFUpuzmDrZgCZEmbvv+Y3CqanV4nIz2WrdvwdK40I=; b=a/phELNqWFuPrxvX20lomMFi/zWrWY0d284qGLKfLVODI8lZogy/IvrYnQL3/k1+wp oMlxa3vh7k5/sPRh77nLCsutyKHQ0p96qH85WWeomlPwROKg954FJLqu7xHueocaWEfM 8751div+1MPnNE7EUg3TsvoEPNmux6oAenxkDy/+u5aK0BLQAlMKYAFBUfCHm+7BRD8v uKgEFH02j4YiALzDd4yK/7DAvOnNw2rskD61heEzl58ELht9iJ96q1FDFi4eVint+i0O Ug4h3Aj5JjI3F1YHOl4APezy0mLCf5mB9XnFsHYI82ZZHLDhVYFlm3QVbwmthIQkJbrB Mkiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=3lMFUpuzmDrZgCZEmbvv+Y3CqanV4nIz2WrdvwdK40I=; b=HC3s9qgwc1wZkf+AhpDTq/UtmOFcMWbuogumnMau6ewKW2bkMAC2zHfpDgczwauGXt ZVxgc/ghj2Tu7MbhyDPSe9zm0nLQjEnobVkC+Fvasl0ib9RKth0lVCSC866gb9D16oBf G89v/S4cEoqFaCBY4jvf9nibXggyAZyzdDKeDUBQ/sYiOqEzfBK4OkNYeLTgwnWrltz3 Ro13AXsEjX6QeT6ZRmBhU3aI3jFKh4o1Kaju3FImUVv8ZusNA8VF9Aooe1x38n7NobkL 3z/X1OHgj90CekdJCtFqkKk8PXkbVmRPdWLBfyZftAXQDVXAeQDDqlABjlqNgdzjIB6S TO8g== X-Gm-Message-State: AOAM530Uu2iLMdiqegxYGqm7Z+yGEvsUS2NivrEnTrzbCOCVThayc3v0 483bK2krvi6xI1Z3Dnj04wTWEg== X-Google-Smtp-Source: ABdhPJx7vz5Tjzp6HPpH+TL09qsgGH47pLFEkQtKCs0XfUwOgrbhP0vy/IqOuRArQZwes+No6gOlMQ== X-Received: by 2002:a05:622a:134f:: with SMTP id w15mr49770170qtk.561.1641409712040; Wed, 05 Jan 2022 11:08:32 -0800 (PST) Received: from [192.168.45.37] (c-73-125-89-242.hsd1.fl.comcast.net. [73.125.89.242]) by smtp.gmail.com with ESMTPSA id a38sm32913010qkp.80.2022.01.05.11.08.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Jan 2022 11:08:31 -0800 (PST) Message-ID: <4e443a9e-e024-d641-14cd-e36ef7cae46d@philipmcgrath.com> Date: Wed, 5 Jan 2022 14:08:30 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-US References: <082a81964a43ae5f735ad2ca433d0dfe00859c35.camel@gmail.com> <20211230073919.30327-1-philip@philipmcgrath.com> <20211230073919.30327-6-philip@philipmcgrath.com> <7d5dd434d7750123fa32cb623df0463d60d3f82f.camel@gmail.com> <23eaa7e6-c087-d885-924a-192917758bbf@philipmcgrath.com> <5b83ba5e35af7ac956a6d5de41cb98a892863b55.camel@gmail.com> From: Philip McGrath In-Reply-To: <5b83ba5e35af7ac956a6d5de41cb98a892863b55.camel@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1641409820; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=3lMFUpuzmDrZgCZEmbvv+Y3CqanV4nIz2WrdvwdK40I=; b=WitnVc729U4SlM0VfrKs0rrSyoyOGVZafHwAesiyvRMS/Nl8MCn5+JqiHoGdIERYm+6y2d PXcpIXyH8DzzFhAUh84IIMgvQGU07OF+txH56BvKKFovT0Dr2Egnu59iDWZUFeUNCwejSc YBpQUXC00sdzwYExwlUs3LA8Y7rFZ7LsvP9x5ZJX68u2pIfY5TzjXZJWjW4qsO6MiMk9bi u2o/hc/eN48lJ4e8bMvy3AoMAIiwXkN374KmhKMjR5TTlnh5QGvfy8Zv1hIe/eObz2yOlC YPdVmyn1TdnIhYJB/o9t+umZvqF4Xw1bMHwYlWZonbwTj/3jtcz9MPDihp1wJQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641409820; a=rsa-sha256; cv=none; b=A0W4ds8ZR9oZCTJF+BeWfpmdbaGoJRWX5+noG+tvlPbF9g9Ut/bZlwqkgzBMVMcHtyuzbk awRDcshIUuSIE2bKZlP2SYwoKrU72MJBmJGspgPnIOdZP5LE0LiiIvcXdWw5RYO9yZqe3g U8hOXCqEwvmBVBu/jr7ravcA8Bw4HeV2rVoKZLZvNxiVHk0r2m4I5qoL7asY+oM44WaLmb yjHTlTX4CeJhJ5Lg9hmeFzPWOyoQikU3pi59a9zY6Ma7z/zQZZ2HJHWRtB7mez451Jo4bA LOjLDvlaPOAcBx8qB0rTPChVoJeI9JnM2e1S+C0z/YJCPsDWAkrxMstOAhqtrg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=google header.b="a/phELNq"; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: 0.90 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=google header.b="a/phELNq"; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 7BA002C0B3 X-Spam-Score: 0.90 X-Migadu-Scanner: scn1.migadu.com X-TUID: ezuI5qPXSDzf 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 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