GNU bug report logs - #77231
[PATCH javascript-team 0/6] Improve importer and build-system.

Previous Next

Full log

View this message in rfc822 format

From: Nicolas Graves <ngraves <at> ngraves.fr>
To: Jelle Licht <jlicht <at> fsfe.org>, 77231 <at> debbugs.gnu.org
Cc: jelle.licht <at> fsfe.org
Subject: [bug#77231] [PATCH 4/6] build-system/node: Add phase 'delete-unwanted-dev-dependencies.
Date: Tue, 25 Mar 2025 08:19:23 +0100

On 2025-03-24 22:24, Jelle Licht wrote:

> Thanks for working all of this though, I really appreciate it all! I've
> applied patches 1, 2, 3, and 5 locally, and after doing some sanity
> checks over night, will be pushing it to the javascript-team
>
> W.r.t patches 4 and 6;
> A hardcoded list of ignored inputs as part of the build system seems
> like it will tightly couple package expressions to a particular version
> of guix. Changing it in the future (by adding or removing things) will
> also be annoying for packages in guix, as well as generated package
> expressions 'in the wilds'.
>
> A similar argument was better framed in the discussion around
> issues.guix.gnu.org/51838 (warning: long read).

I did the same for python in 68315.  Wasn't aware of that discussion
indeed.

A good general (not Node specific) altenative IMO would be to have
"development-inputs" that are NOT injected in the build/derivation
neither evaluated (when <package> is compiled) but whose names could be
made available as an argument to the build-system.  That makes it
uncessary to record them at the build-system level (although adds more
package boilerplate).

Python basically has the same issue with a lot of false/unrequired
native-inputs.  I think I heard Nix solves this with a concept similar
to what I describe.

> The idea of having the importer be able to effectively ignore a large
> part of the huge dependency graph if we know it won't be useful to us is
> a cool feature to have. Ideally it'd somehow be part of the generated
> output as well though, so the generated package expressions run on more
> revisions of guix.

Do you mean we should do that as a snippet or in an earlier phase?

> Tangentially, how did you run into issues with this particular list of
> deps?  Are they not often encountered as devDependencies (and
> subsequently explicitly removed in the package expressions generated by
> the importer)? Or is the point to minimise (generated) code duplication
> between packages to remove these ne'er-needed-deps?

The latter, but it felt needed for some reason, the sheer count of lines
and readability is consequential.

>
> Thanks again!
> - Jelle

-- 
Best regards,
Nicolas Graves

Previous Next

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