From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.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 AKytDwkQ2WG6lQAAgWs5BA (envelope-from ) for ; Sat, 08 Jan 2022 05:16:09 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id QJtKDAkQ2WFBDwEAauVa8A (envelope-from ) for ; Sat, 08 Jan 2022 05:16:09 +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 AF70B4003E for ; Sat, 8 Jan 2022 05:16:08 +0100 (CET) Received: from localhost ([::1]:36128 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n639D-0000JZ-Rh for larch@yhetil.org; Fri, 07 Jan 2022 23:16:07 -0500 Received: from eggs.gnu.org ([209.51.188.92]:42568) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n638C-0008Sb-Ui for guix-patches@gnu.org; Fri, 07 Jan 2022 23:15:06 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:53295) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n638B-0003P2-EO for guix-patches@gnu.org; Fri, 07 Jan 2022 23:15:04 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n638B-0001VV-AR for guix-patches@gnu.org; Fri, 07 Jan 2022 23:15:03 -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: Sat, 08 Jan 2022 04:15:03 +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: 51838@debbugs.gnu.org Cc: Timothy Sample , Pierre Langlois , Jelle Licht , Liliana Marie Prikler , Leo Famulari Received: via spool by 51838-submit@debbugs.gnu.org id=B51838.16416152545688 (code B ref 51838); Sat, 08 Jan 2022 04:15:03 +0000 Received: (at 51838) by debbugs.gnu.org; 8 Jan 2022 04:14:14 +0000 Received: from localhost ([127.0.0.1]:46196 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n637N-0001Te-Ux for submit@debbugs.gnu.org; Fri, 07 Jan 2022 23:14:14 -0500 Received: from mail-vk1-f174.google.com ([209.85.221.174]:38871) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n637M-0001TC-Fh for 51838@debbugs.gnu.org; Fri, 07 Jan 2022 23:14:12 -0500 Received: by mail-vk1-f174.google.com with SMTP id h5so4911450vkp.5 for <51838@debbugs.gnu.org>; Fri, 07 Jan 2022 20:14:12 -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=5waxBRsxid+/jvF77W5lZGt/tvIk6rY2VGm5whlLwwk=; b=PnLfh+KfM4jqFJXputl1lj8wqYUNcITP8wc7+2cqjgJP8ocFLYW+17RHr3CAKxrdFl 5yCuPk/qeymMpMqRR3hCTb/SCDB+E88YRHc85YMbt9LU4P3NGud0ib5oNPphxpOyyVgY G+k2YiGSZOLPw5VqEWRyEqxnUA9xQ1kh+EBgGH3hI+/R4HXiDa6p8Exb19jWOJpkpKcW QwuzKphe7mcOgNRVJhiY6p0zduKmoEN8dx6wdWcIxRjDQ8jqrA5lUJD/bpiRAVM6oVe5 Cg8BD9lR/yOGiy1J4+UI+SB3JDXSXFTkhVjFXNyXE+EF5fZh45945i6a8QCCpYwP5Tki T/+w== 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=5waxBRsxid+/jvF77W5lZGt/tvIk6rY2VGm5whlLwwk=; b=2ReONJLOzBQHWhn1dUIRLeyR/Y/l/soxxrxcfbxT+qKnHWQeebGyZ9HfwQB4QjVlAt 4xZSbLjeGRVvcSXTndAmxoIMyr2PDawnKVvb2nUpggqDg2LSW/P/CF9n45IqgLqhN+9n 63rNhciBJJsXi8MqVYW7bLNYN62q0YBUfPJTMBf/O7xLQmi4sTba28o4C757f914sYpk BhdpaRWsd2tjwXMBrsLVKF7gqJ0FW6DE+qaRz2QWUNa+bdta46bb4gX+Ou0yihFvk/eR YUXQv05wuqYLg3LvDXFIp3GKBRNq+PsAgyN6IiHXwNGGHNm7BfHwn4Vmy2kAEP7WZ2GB cNbw== X-Gm-Message-State: AOAM530eku6JlgBJu3J+v/hlDIL2sXED6BxdOfWcL1lZNpsAvF5sW3pr 6qbPaCeN26vNOqOk9qfpLQGLohuxU5uverxE X-Google-Smtp-Source: ABdhPJzqjhc0uMivTDL2uzMo8lN1XamDchb7LE6QhVOp20+2GKSE20EKuRgQlGJewoMQHDuEQnPzjQ== X-Received: by 2002:a05:6122:2c3:: with SMTP id k3mr690508vki.14.1641615245805; Fri, 07 Jan 2022 20:14:05 -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 v7sm349711vkc.31.2022.01.07.20.14.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 07 Jan 2022 20:14:05 -0800 (PST) Message-ID: <441bfeb0-eb6e-81f6-488b-cdf1b09a78ef@philipmcgrath.com> Date: Fri, 7 Jan 2022 23:14:04 -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> <7b04af28bbd57c67093ce8f33a648efec89693bd.camel@gmail.com> From: Philip McGrath In-Reply-To: <7b04af28bbd57c67093ce8f33a648efec89693bd.camel@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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=1641615368; 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=5waxBRsxid+/jvF77W5lZGt/tvIk6rY2VGm5whlLwwk=; b=YB3nyYAlZc8o4rQoTyqBQg9SbVGjonn8Qke1ucHJXMJU8na1qy0H4kQX98JGbHqhfGVVaL mgFnIB6qSWFQY8kR0DA5kDj7hzkS5YrCca9mH3zDNdOofHih4h3r0KZsxxx39um9whQq+e cQZ8VD3YGjmFJJxepLRT4cfQSvJKXdXe5valLMod+7rsf8HLqYuDqmydzXE7aiyQEWCvoy +F3DdADlXe54DGhDur98CiqVVe7uHawXIUuiL6tFjERW9TggwbeW2mnWmp9+E4JYH57WqC MPuOHGDHkIxrDzlLmnePlgoUJqcqXzUTbwPvkp+4QLjxLjvLP8w1IkDaDmFpdA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641615368; a=rsa-sha256; cv=none; b=nsOfDxuV/zrmzHPovMQocbVTIa/goWRaR9ZbgL472xCKsOv5XzTaBlm+SyGEh0UL874G7w bToCufH/NqIlFLbtv6dUMuGDoU1FSaDXxqptlwjZSxpfgMwpYaUEl7wjrV+uGQOl9kKT3w C9lhCA+VJnQ48dbZEDCRIjUFL+8yJ2UlgBya6sa/MrJ93/vToJZgy/e1up/zBXPwK/6EzJ YDs7DilJF5E76kNQDcBR6RPMulsWMQHZIE8PJ2zHpeTI+yUlCBZEZ4xI/A8NPIkejdHgyz NMiX751LRKCptXyQKrKzJtjkEVqdqg2/jYP76FgU18P3AytgY7Rs4AuZLH0nEg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=google header.b=PnLfh+Kf; 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: -1.60 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=google header.b=PnLfh+Kf; 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: AF70B4003E X-Spam-Score: -1.60 X-Migadu-Scanner: scn0.migadu.com X-TUID: SdNKD1R9T/ZZ Hi, On 1/7/22 18:47, Liliana Marie Prikler wrote: > Hi, > > Am Freitag, dem 07.01.2022 um 17:11 -0500 schrieb Philip McGrath: >> I think this is not quite correct. >> >> (Actually, I suspect more broadly that node-build-system's handling >> of peerDependencies is not quite correct, but wrapping my head around >> the semantics of peerDependencies is on my to-do list for after these >> patches are applied. Here's one thing I want to read and understand: >> https://pnpm.io/how-peers-are-resolved) >> >> NPM does not try to install packages in "peerDependencis" during 'npm >> install' (out 'configure' phase). The problem arises because because >> our 'patch-dependencies' phase adds the "peerDependencies" as >> additional "dependencies". (Why? I don't fully understand, but I >> guess because it wants them to be installed.) We want absent >> "peerDependencies" to not be listed in "dependencies", but I don't >> think we want to delete them from "peerDependencies": at a minimum, >> we do not need to, and it seems like it might cause problems that I >> don't fully understand. >> >> (This is one of the reasons I preferred to handle absent dependencies >> in the 'patch-dependencies' phase.) > I'd like to be able to understand that too, but npm still boggles my > mind. I mean, I did start writing this patch series because I find it more understandable than just using npm :) > I think node-build-system's implementation is a rather pragmatic > one; it forces you to use just a single combination of versions for all > of those rather than relying on node trickery I will send a v9 that doesn't delete "peerDependencies" and just rely on doing the ordering properly. Hopefully, we can improve the situation later, once we understand how "peerDependencies" are actually supposed to work (and/or adopt '#:absent-dependencies' :) ). I don't know of any concrete problems that would be caused by overzealously deleting "peerDependencies", but I wouldn't know of them, since that's not the behavior I've been testing all this time. > (on a related note, > perhaps we ought to make inputs in node-build-system propagated-inputs > to be on the safe side). I think that might not actually lead Node.js to find all of the modules, and some things I've been reading with interest (but not yet fully understanding) suggests that the opposite, i.e. creating a more strict "node_modules", is actually useful. [1] [2] > >>> 4. Regexps :) >> >> Hopefully addressed in my previous email :) Jelle makes good >> arguments for the no-regexps side. I'm genuinely on the fence, which >> suggests to me the best course might be to leave it as a possible >> future extension (as we're doing with '#:absent-dependencies'). > We do already have threads on the regexp thing, so I'm not going to > respond here to keep it manageable. The change is a rather small one > inside node-build-system itself, but you have to expand those strings > again ;) I am not 100% clear---if I'm wrong, please speak up!---but my sense from the previous thread is that: 1. some people have reservations about some regexp proposals; 2. everyone who has liked any of the regexp proposals has been ok with one of the options for distinguishing regexps from non-regexp strings, either '(regexp "foo") or (make-regexp "foo"), with another dimension being whether or not to require full matches; and 3. with either of the options from #2---as long as regexps are using some representation that answers #f to 'string?'---regexp support could be added as a fully compatible future extension. So I think---I hope!---a version without regex support could get everyone's assent. Unless someone tells me otherwise first, that's what I'll do in v9. >> Time permitting, I'll send some more comments, but the only things I >> think need to be addressed before merging are peerDependencies and >> regexps. > Cool. Let's just not forget to send a v9 once we have what looks like > to be a reasonable action (assuming it's not a do-nothing, in which > case I just need to reword some of your commit messages again). In my > personal experience, patches help a stalled discussion tremendously. Ok! -Philip [1]: https://pnpm.io/blog/2020/05/27/flat-node-modules-is-not-the-only-way [2]: https://medium.com/pnpm/pnpms-strictness-helps-to-avoid-silly-bugs-9a15fb306308