Subject: [bug#51838] [PATCH v8 00/41] guix: node-build-system: Support compiling add-ons with node-gyp.

From: Liliana Marie Prikler <[email-masked]>
Date: Fri, 07 Jan 2022 20:43:32 +0100

Hi,

Am Freitag, dem 07.01.2022 um 11:49 -0500 schrieb Timothy Sample:
> Liliana Marie Prikler <[email-masked]> writes:
> > 4. Regexps :)
> 
> I doubt regex support will be broadly useful here.  Putting the
> anchors in every package name (e.g., "^tap$") makes for a lot of
> noise.  My (wild) guess would be that regexes will save us listing
> two dependencies for one out of every ten Node packages.  Given that,
> my preference would be to not bother with regex support.
My reason to include them is that we can already see a number of
packages requiring typescript(.*) for a number of (.*) -- similarly
karma and mocha -- in the patch set given by Philip.  I do think
regexps will be less useful later on and could very well become
obsolete by the time we have a full bootstrap of everything, but we
don't have an ETA on that, so for now I'd like to have that capability.

I see two potential solutions here.  First is matching the whole string
as you suggested and discussed below.  Second is opting in to regexp in
general (there are some ".js" things, that would otherwise require
escaping).  This would take the form of the user writing
'("foo" "bar" (regexp "^baz$")) as UNWANTED, and it'd be interpreted as
the predicates
(equal? S "foo") ; alternatively string=?
(equal? S "bar")
(string-match S "^baz$")
WDYT?

> > I think it'd be beneficial if delete-dependencies could delete
> > dependencies based on their name matching a regexp rather than a
> > string exactly.  This would make some of your lists shorter
> > (e.g. "karma.*"), but there might be a debate on whether to use
> > "^karma.*$" or whether to only consider regexps that match the
> > dependency fully.
> 
> If nothing else, I’m certainly on the other side of this debate!  :)
> If every string is going to be treated as a pattern, we should have
> it match fully by default.  That is, the anchors should be implicit. 
> For the very rare (never?) case where you want to avoid anything that
> so much as has “foo” in the name, it’s pretty easy to write
> ".*foo.*".
Full string matches are my preference too, but I only found the
function that does partial match.  Is there an easier solution than
checking whether the matched string equals the input to string-match?

Cheers