From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id IOE9Ebur2GEscAEAgWs5BA (envelope-from ) for ; Fri, 07 Jan 2022 22:08:11 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id oG3ADrur2GEzNgEA9RJhRA (envelope-from ) for ; Fri, 07 Jan 2022 22:08:11 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 658F63A8AF for ; Fri, 7 Jan 2022 22:08:10 +0100 (CET) Received: from localhost ([::1]:59534 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n5wT3-0006hX-Jx for larch@yhetil.org; Fri, 07 Jan 2022 16:08:09 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38918) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n5wSw-0006h7-Pf for guix-patches@gnu.org; Fri, 07 Jan 2022 16:08:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:53084) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n5wSw-0004PG-Hk for guix-patches@gnu.org; Fri, 07 Jan 2022 16:08:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n5wSw-0001wg-8q for guix-patches@gnu.org; Fri, 07 Jan 2022 16:08:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#51838] [PATCH v8 00/41] guix: node-build-system: Support compiling add-ons with node-gyp. Resent-From: Philip McGrath Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Fri, 07 Jan 2022 21:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51838 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Liliana Marie Prikler , Timothy Sample Cc: 51838@debbugs.gnu.org, Pierre Langlois , Jelle Licht , Leo Famulari Received: via spool by 51838-submit@debbugs.gnu.org id=B51838.16415896567427 (code B ref 51838); Fri, 07 Jan 2022 21:08:02 +0000 Received: (at 51838) by debbugs.gnu.org; 7 Jan 2022 21:07:36 +0000 Received: from localhost ([127.0.0.1]:45987 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n5wSV-0001vi-RM for submit@debbugs.gnu.org; Fri, 07 Jan 2022 16:07:36 -0500 Received: from mail-qt1-f175.google.com ([209.85.160.175]:34632) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n5wST-0001vM-K1 for 51838@debbugs.gnu.org; Fri, 07 Jan 2022 16:07:34 -0500 Received: by mail-qt1-f175.google.com with SMTP id o17so6823484qtk.1 for <51838@debbugs.gnu.org>; Fri, 07 Jan 2022 13:07:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=philipmcgrath.com; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=Lg0Fvsjuzp/WuiS2VqT51N3BumIadWaxG8eB7SUHnQs=; b=d1W5xo9Iq7raSCXjeL6hrHj0nlvlka0vixA50n57khhXvhurV2E4Sl5F/nsqf5Ml8T 9iaDUceyeKn9duOuQAW1g9ryzO+vGKTA9hGTrVqqyBJSyWq58Mnv8O/JAArRXK+x2xIj ZkZzDBA0YPFSeolEj4sjy4BUBk/Z9hLmXnb6CJbsXneZDGLVPNo7HPVNw9kte1I9RzAn 2qnvVM20CqQhzWVfBP4NrLEwGKk1VZdDWl8Cw+wwfqmnaxYaCbiSPuvRfnyHBUUDTmWx 1ODJzT5UTKpfSxudlYh6bBAPSEFNuwSdgHEmnUcTl06pnqhwWAGEsfiEsbjYZ1tI8GnK AtpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=Lg0Fvsjuzp/WuiS2VqT51N3BumIadWaxG8eB7SUHnQs=; b=wja224Pr1veM9SyRUi2gyNQvSW2OQN236qkiNQx8ZGuXNk4Q4P9sa3F9Ov2P/h/FBQ GQWxCjRvY7khPaUdcKAutCtci0mfiEnv2i29qP8Jil+HTKoioBaKHBy0dCH12gykceeU SGg9asoyxyAAXf6zz2/+fWGh6YsD+8wMxQPU0VdHX0lGE4sSGhEOAICq2YUUvDdC1qRd AharViQLxecyfVBsnlICC2yCpDtISbbVo+EInTkh8Xw7A3zShcHGyWG9uRUoi/9+xCC9 y30hq6qCRq5Bf4rLJ2PI/zVoyXyx1PSS+XhdgLJPit0YFqoAj0YzrROHJpL2+ViQf17X Iwyw== X-Gm-Message-State: AOAM5310h05eg3Zz9dQxGLkoU87N7sIaH+YtF/3OycpJriXYv8vlHLVV mJrhCEmzExdl1hRSlizQPTjcIA== X-Google-Smtp-Source: ABdhPJwzvczKshy1DEGr2x8BKCQdZwQ5dqVjJ7yZF62Pu8W0fQSQPbsRB/zBxrmoS9x0Ws8DdvSD4A== X-Received: by 2002:ac8:5955:: with SMTP id 21mr8599221qtz.246.1641589647982; Fri, 07 Jan 2022 13:07:27 -0800 (PST) Received: from [192.168.45.37] (c-73-125-89-242.hsd1.fl.comcast.net. [73.125.89.242]) by smtp.gmail.com with ESMTPSA id t5sm3903971qtp.60.2022.01.07.13.07.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 07 Jan 2022 13:07:27 -0800 (PST) Message-ID: Date: Fri, 7 Jan 2022 16:07:26 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-US References: <64e08d3a1838ed8507f33fae895545372960522f.camel@gmail.com> <87v8yv1ofd.fsf@ngyro.com> From: Philip McGrath In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1641589690; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=Lg0Fvsjuzp/WuiS2VqT51N3BumIadWaxG8eB7SUHnQs=; b=u1G/lARFc9KtCRfR/sml4adpaLJp7ZiObMiFJkeLJGg+jD2780y1s0l0C+Vnxty7NGNLp3 uma0fAbgS4ULs1LLY/21wCTJFWSZFaNGbtOOd2i5alOFR5H/QUx59of6ULDRlHJ3I924L/ hZo/IatTpt+2mvFtGVAPXvKbXacNvdATtEZ/GUKmP/2leVTlfSZPRccKJ6oPQqviZwd5BV ekcFMLkE3u4KmMLyOMFMljnCJ2VKEZLfAQRnbBKxS2ZRUqGypvTUjFXc/BmGdgdODFeeY9 ROstaOkYDcr8knk04qZK4Gv+pF7IuiGH6puWkHrD4bziyNAyMdzaTj3evahfMg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641589690; a=rsa-sha256; cv=none; b=aFWYB4ZcG9DQ1u0u7XO8p0UbLshOVVTuYDHv9ybdTC5SZV7X+Y3HoDwj/K0LPMCuwNMqeK sPfbUHHL9LBOq3d+8I7KjH3arclJMieRxfWlCqqeti3ciH8RKoRDW30uqglRSkKY36Lya8 P5KZ9ZSeaj1EqLvl4yCxm+fSncJgPXCCwLgrh9S+VfGIlDXqxfEUZyYL5plN0ysMJ271vT 7UgadDOrCGxk3qYoEAjcFcvXzJ0p8FZhLP6USXUhSA5gvDJO73bTZq0L6qv3ptSp0Ap/EW fqVA8x3As4oEcIY+9bDkfc3KEIa3o8YZ1/O+OL77n689qMOZfy/IA4rzGCAa4Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=google header.b=d1W5xo9I; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -0.60 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=google header.b=d1W5xo9I; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 658F63A8AF X-Spam-Score: -0.60 X-Migadu-Scanner: scn0.migadu.com X-TUID: CrFZAkB/VS6N Hi, I'm excited to take a look at this! On 1/7/22 14:43, Liliana Marie Prikler wrote: > Hi, > > Am Freitag, dem 07.01.2022 um 11:49 -0500 schrieb Timothy Sample: >> Liliana Marie Prikler 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 think I agree with both of you, with all of the countervailing considerations. My base position is that regexps should not be mandatory or default. It was very convenient to be able to just copy--paste package names from "package.json" into '#:absent-dependencies' (or whatever). I can imagine it being useful for tooling, too, to be able to find just from the package definition the dependencies which are being deleted, rather than having to either download the origins or try to reconstruct names from regexps. But I do know that there are some families of Node.js tools we don't have packaged that come as a bunch of related "devDependencies", and I can see the convenience of being able to remove, say, "@types/.*", "eslint-.*", and ".*-webpack-plugin" succinctly. Ultimately, I agree with Liliana that the right solution to those missing tools is to package them for Guix! My experience so far with workarounds like esbuild is that they are very useful for bootstrapping and pragmatically producing usable packages, but that trying to replace the build tooling of the entire Node.js universe by hand is not a viable solution. (To be slightly more specific, I've encountered some problems with conflicting expectations about whether to consume and/or produce ES6 vs CommonJS modules, for packages that are more like "libraries" than "applications".) I think it would be fine to remove the regexp support, at least for now. Alternatively, I would also be ok with ... > > 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? the second proposal, or a slight variant on it in which the user would write: `("foo" "bar" ,(make-regexp "baz")) Since this (either variant) would not change the interpretation of strings in the list of dependencies to delete, it could also be added later without breaking compatibility. > >>> 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? I also think full string matches are better, regardless of any of the above. Here's an implementation that avoids unneeded copies and string comparison: (define (regexp-match-exact? rx str) (define m (regexp-exec rx str)) (and m (= (match:start m) 0) (= (match:end m) (string-length str)))) (This should also avoid repeatedly compiling the regexp, as 'string-match' would do.) More soon, I hope! -Philip