[bug#51838] [PATCH v5 07/45] guix: node-build-system: Add #:absent-dependencies argument.

[Philip McGrath]

Hi Jelle,

Here's a short answer to one specific question:

On 12/20/21 18:10, Jelle Licht wrote:
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> > Am Montag, dem 20.12.2021 um 14:33 -0500 schrieb Philip McGrath:
> > > I can see pros and cons to both approaches. I still like
> > > `#:absent-dependencies` better, as I find it less verbose, more
> > > declarative, ... trade-offs we probably don't need to rehash further.
> > > But it sounds like you see a huge, prohibitive downside to
> > > `#:absent-dependencies`, and I am just not managing to see what that
> > > is.
> > If you want something that's not verbose and declarative, implement
> > #:strict? #f.  #:absent-dependencies is extremely verbose for what it
> > achieves, particularly when we think about the implementation as well.
>
> This would be the equivalent to 'magically' patching out any dependency
> that guix can't find. I like it in principle, but how is this
> functionally different from the current approach of simply not checking
> any node dependencies by deleting the configure phase? Perhaps I
> misunderstood something somewhere along the way.

One key difference between the proposed `#:strict? #f` and the current 
status quo of `(delete 'configure)` is that, at least as I've understood 
the proposal, the patch-dependencies phase would still remove the 
(implicitly detected) absent dependencies from the "package.json", so 
the configure phase would be able to run `npm install`. That would fix 
the problem I described back in <https://issues.guix.gnu.org/51838#13> 
(a month ago), and the native packages would successfully build.

I think it would be a less good option for the reasons you state, and 
which I've argued for elsewhere, but it's important to be clear that it 
would solve the problem building these packages.

Actually, in an ideal world, I would agree with Liliana that 
#:absent-dependencies ought to be out of scope for this patch series. 
However, the existing solution for the problem of missing 
dependencies---deleting the configure phase entirely---does not work for 
packages that need to build native add-ons. So, if I needed to solve the 
problem for the native add-on packages, I thought I should find a 
generally-applicable solution that, in my view, is an improvement for 
the existing packages as well.

More soon,
Philip