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 #791 received at 51838 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Timothy Sample <samplet <at> ngyro.com>, Philip McGrath
 <philip <at> philipmcgrath.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 23:00:08 +0100
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.e.

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

although delete-dependencies could even be some chain of alist
rewriting procedures if we wanted to be super evil.

I don't think we would need to generate phases through FP, we can write
them as code.

> > I don't know what further steps to take to resolve this
> > disagreement or how some decision ultimately gets made.
> > 
> > Maybe someone else could weigh in on how to proceed?
> 
> 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.

Cheers




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.