GNU bug report logs - #51838
[PATCH 00/11] guix: node-build-system: Support compiling add-ons with node-gyp.

Previous Next

Package: guix-patches;

Reported by: Philip McGrath <philip <at> philipmcgrath.com>

Date: Sun, 14 Nov 2021 12:43:01 UTC

Severity: normal

Tags: patch

Done: Liliana Marie Prikler <liliana.prikler <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #803 received at 51838 <at> debbugs.gnu.org (full text, mbox):

From: Philip McGrath <philip <at> philipmcgrath.com>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>,
 Timothy Sample <samplet <at> ngyro.com>
Cc: 51838 <at> debbugs.gnu.org, Pierre Langlois <pierre.langlois <at> gmx.com>,
 Jelle Licht <jlicht <at> fsfe.org>
Subject: Re: [PATCH v5 07/45] guix: node-build-system: Add
 #:absent-dependencies argument.
Date: Mon, 20 Dec 2021 22:59:05 -0500
Hi all,

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 <at> 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 could live with the above as a compromise.

My reservation regarding:

> 
> (add-after 'patch-dependencies 'drop-junk
>    (lambda _
>      (with-atomic-json-replacement "package.json"
>        (lambda (json) (delete-dependencies json '("node-tap"))))))
> 

is that `with-atomic-json-replacement` would make (guix build json)'s 
representation a part of node-build-system's API, which it currently is 
not. For the reasons I detailed in my last email, I think that would 
open up a larger can of worms than it might seem.

Liliana, I'm not entirely certain, but my impression from:

>> I’m probably not “someone else” enough at this point, but I guess we
>> can ask the maintainers to weigh in/help facilitate.  We try to move
>> forward by consensus, and maybe replacing the keyword with a phase-
>> making procedure will get us there.  Liliana, what do you say?  Have
>> we found an approach we can agree on?  If not, I think that we’re
>> probably stuck and will need some fresh voices to move forward.
> I personally think phase making is out of scope and we need a solid
> foundation first.  That said, if Philip does provide both that
> foundation and a good reason to have a phase-making procedure, I'm
> willing to strike a compromise.

was that you would still have objections to something like:

>>> ```
>>> #:phases
>>> (modify-phases %standard-phases
>>>    (add-after 'unpack 'delete-dependencies
>>>      (make-delete-dependencies-phase '("node-tap"))))
>>> ```

unless it came together with code like `with-atomic-json-replacement` 
for more general "package.json" transformations.

If that's the case, then I guess we should do as Jelle suggests:

On 12/20/21 18:10, Jelle Licht wrote:
> I believe the best thing to do would be to push the earlier
> uncontroversial node patches.
>
> Perhaps we can get some of the gurus/victims of other build systems
> involved on guix-devel as none of the fundamental issues you've been
> talking about for a while are node-specific. As long as we want to reach
> some kind on consensus, I believe writing/reviewing more code does not
> get us to a desirable outcome at this time.
>
> - Jelle
>

-Philip




This bug report was last modified 3 years and 197 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.