From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 6AJDIqjfwGFR5wAAgWs5BA (envelope-from ) for ; Mon, 20 Dec 2021 20:55:20 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id 2GTcHajfwGG7HgAAB5/wlQ (envelope-from ) for ; Mon, 20 Dec 2021 19:55:20 +0000 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 217101648B for ; Mon, 20 Dec 2021 20:55:20 +0100 (CET) Received: from localhost ([::1]:50012 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mzOkh-0004P7-7A for larch@yhetil.org; Mon, 20 Dec 2021 14:55:19 -0500 Received: from eggs.gnu.org ([209.51.188.92]:36882) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mzOkQ-0004N3-QH for guix-patches@gnu.org; Mon, 20 Dec 2021 14:55:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:39981) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mzOkQ-00026j-I8 for guix-patches@gnu.org; Mon, 20 Dec 2021 14:55:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mzOkQ-0002Wi-B7 for guix-patches@gnu.org; Mon, 20 Dec 2021 14:55:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#51838] [PATCH v5 06/45] guix: node-build-system: Refactor patch-dependencies phase. Resent-From: Liliana Marie Prikler Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Mon, 20 Dec 2021 19:55: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: Philip McGrath , 51838@debbugs.gnu.org Cc: Timothy Sample , Pierre Langlois , Jelle Licht Received: via spool by 51838-submit@debbugs.gnu.org id=B51838.16400301019702 (code B ref 51838); Mon, 20 Dec 2021 19:55:02 +0000 Received: (at 51838) by debbugs.gnu.org; 20 Dec 2021 19:55:01 +0000 Received: from localhost ([127.0.0.1]:51527 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzOkO-0002WP-GP for submit@debbugs.gnu.org; Mon, 20 Dec 2021 14:55:00 -0500 Received: from mail-wr1-f67.google.com ([209.85.221.67]:39775) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzOkM-0002WC-Nm for 51838@debbugs.gnu.org; Mon, 20 Dec 2021 14:54:59 -0500 Received: by mail-wr1-f67.google.com with SMTP id s1so16888890wra.6 for <51838@debbugs.gnu.org>; Mon, 20 Dec 2021 11:54:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=KsQs1K4+k3izBG1rLvVNQvOr9LCECFxeX0XWXLIsxNA=; b=LM3ol8Nj5gJG/Pyk77x2RfFHzXoAPO+vxLQakOnzmxKxEXN46VNvkMZxoWUShAe6ea F2kYqGQaqoJ4dGbc3pkzzXz7PUvjifmQnKwkIoqyUCk1UTEAKmuWZwJrR0IfyLj1Idn2 rncgMPGNvq5brVGbFPQMA2eZkPC694gh0ZQ5fuoM+YHIFOOw/ai0ylRUX5Ntoc+kfGwO 9pecDAARocnnPR01hqO10rAFAO89rnX3sTmLHEpLHkXFf5wgo44HAgVAxWeACO8H1rhV V0bgMMtWY7MxC1zolWXUrT3Epfj088tuhrfYlx8vPxYEgSX5QIE2Sl3Yuvn7/1WgJ3vb uydg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=KsQs1K4+k3izBG1rLvVNQvOr9LCECFxeX0XWXLIsxNA=; b=DLWtxb8qb2Ou/5IsECSDTYA8VG66X8UyXDfYtFnk72H+DC64qvkkNpa8Msx9PMc9k/ GnpoRH/8oACMdv43Q85VYJ5+1G8UrEqBUQ8Gxr/RN6ArrLi081+AWh+R3lMVxBqDlFRh ruXSMBASt+m2CqaHyvozRvq9FhlARDYc6elIS0gFxg/+U1NE1nyWKpjd+i2mn3cksxWN aIn2fOHHkwQvay/xH/fQeu4IC7A+laiCMeFVcVdVIANcDeylxQ1Atm15s6wjaAjIsZTM TjtgJjuT7i3u7CnlAaoFOJIak+hZvq+ywTFU+Z2/Cre9gTn04NrzBtGwPORRcVWKp8q9 uCGw== X-Gm-Message-State: AOAM532WtfQ5F7vZt7VDw36giIo1UYWLAf7IAA7JF3VhcSM7mBY4U822 NJk39uko2rOJZqU+kj6P6G4= X-Google-Smtp-Source: ABdhPJyB6pXHcwE+Nh6F+k5TuIR11nRXyzLS+gbQTQT0xdLgoWntBeurxcZpYvYOf61/oY8ug7+vgw== X-Received: by 2002:adf:ba8b:: with SMTP id p11mr10959725wrg.390.1640030092766; Mon, 20 Dec 2021 11:54:52 -0800 (PST) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id b13sm16843014wrh.32.2021.12.20.11.54.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Dec 2021 11:54:52 -0800 (PST) Message-ID: <60154db1c83f2f21368fbd3157929f66c916da52.camel@gmail.com> From: Liliana Marie Prikler Date: Mon, 20 Dec 2021 20:54:50 +0100 In-Reply-To: <4fead57b-66f0-a0e8-cf3b-a65a8ecba1b2@philipmcgrath.com> References: <20211213060107.129223-1-philip@philipmcgrath.com> <20211217020325.520821-1-philip@philipmcgrath.com> <20211217020325.520821-7-philip@philipmcgrath.com> <17f63a58ea9b462e67847f9c7698a119e3915a08.camel@gmail.com> <650d1c43-8106-e7e9-5855-29cfa5f9d147@philipmcgrath.com> <9fe83c79f796bb323816d2c02e45b4277680eda0.camel@gmail.com> <4fead57b-66f0-a0e8-cf3b-a65a8ecba1b2@philipmcgrath.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 MIME-Version: 1.0 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=1640030120; 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=KsQs1K4+k3izBG1rLvVNQvOr9LCECFxeX0XWXLIsxNA=; b=EgxMJBxl+vkDSKg7My7LXJs3znsZxgQ4NAYTj/YeetObn6GntdT/6kJpqyVHZ24gFYbHSZ V1sJGY5KtXvWBrdxqcOrd2SDz3kfOlXzVHAYhSuigeqU29afaSsGs3ZGsETjlofK/+gR5f CPE1eLhPFDX5y7ErOEApx6n4O0PohffgeqANPJc4FH2Z+3K7nDOpk4eFHND5J0d4vOfPZP qPhz9I3JOBbNDXotKEgFj9uB1QPb5MVYLuQ/UM+l4KxuX+bRb2OFk1ofb5RRGwDRRzezPA LzHj+/MV7p/G0kO3bGuusZf0iqEoZl9VUzwaL1IIEl2xCjDDB9/bwz5W4zUlkA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1640030120; a=rsa-sha256; cv=none; b=KdZrhhmMb4e37vwIE9oZECCTa1T7Xa14N+feUjYtmhPeS8KL4viwCPYGREsEkr2GogBqyn J9LP94TCGxvC/dClrm/pdqqsZM2WiybtqdW+IHNhwK6NSzK3YH2weztKcJGQG6ugihy92r jnqd+yYinquYBMRpZb9ygVmE6sqEMR2mbaids55SDCgl/qrctY8RJu+IA8nyjeoQ+IiSjm SMMf7Fgh8O0vlYNa1/IasNL2CDwtS93fi9I7dDktB+eHCvqvt6RaWkbE85Vc+DrZ4DB156 CPJ7qYnPjZ3bOotodD0TKkKR0O7A9pBPoxh6kri+tn5yr5hSC1vd+4dN8SEuwg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=LM3ol8Nj; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=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.42 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=LM3ol8Nj; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=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: 217101648B X-Spam-Score: -1.42 X-Migadu-Scanner: scn0.migadu.com X-TUID: 93N2Th+FnPAN Hi, Am Montag, dem 20.12.2021 um 13:03 -0500 schrieb Philip McGrath: > I definitely am not understanding what you have in mind here. When > you write "strip the @", I'm not sure what you're referring to, > because there are multiple "@" tags here, one beginning each JSON > object. (Maybe this is obvious, but it hadn't been obvious to me.) I'm referring to this part: > + (define (resolve-dependencies meta-alist meta-key) > + ;; Given: > + ;; - The alist from "package.json", with the '@ unwrapped > + ;; - A string key, like "dependencies" > + ;; Returns: an alist (without a wrapping '@) like the entry in > + ;; meta-alist for meta-key, but with dependencies supplied > + ;; by Guix packages mapped to the absolute store paths to use. > + (match (assoc-ref meta-alist meta-key) > + (#f > + '()) > + (('@ . orig-deps) > + (fold (match-lambda* > + (((key . value) acc) > + (acons key (hash-ref index key value) acc))) > + '() > + orig-deps)))) You could simply write the function s.t. (resolve-dependencies DEPS) takes an alist and then produces an alist of resolved dependencies. Because you don't, you need to code around that quirk down in the file replacements. You can safely access the dependencies using (or (and=> (assoc "dependencies" json) cddr) '()) in the calling code. If you replace "dependencies" by a generic KEY, you can also outline that into a helper function. > So, the (guix build json) representation of a "package.json" file > might look like this: > > ``` > `(@ ("name" . "apple") >      ("version" . "1.0") >      ("dependencies". (@ ("banana" . "*") >                          ("pear" . "*"))) >      ("devDependencies" . (@ ("peach" . "*") >                              ("orange" . "*"))) >      ("peerDependencies" . (@ ("node-gyp" . "7.x"))) >      ("peerDependenciesMeta" . (@ ("node-gyp" . (@ ("optional" . > #t))))) >      ("optionalDependencies" . (@ ("node-gyp" . "7.x")))) > ``` Note that '("dependencies" . (@ ("banana" . "long") ("pear" . "*"))) is equal to '("dependencies" @ ("banana" . "long") ("pear" . "juicy")). > An unfortunate consequence of this representation is that JSON > objects are not usable directly as association lists: some procedures > expecting association lists seem to silently ignore the non-pair at > the head of the list, but I don't think that's guaranteed, and other > procedures just don't work.  There are sloppy variants of the assoc functions, but again, you are looking at this from the wrong angle. Just ignore that you have a JSON object and pass the alist to resolve-dependencies, then reconstruct a JSON object from the result. ezpz > In particular, `append` applied to two JSON objects does not produce > a JSON object, even ignoring the problem of duplicate keys. I think we can ignore that for now, but if it bugs you you can convert to hash table and back or at least assert that the keys are unique. > Given that the current code adds "peerDependencies" as additional > "dependencies", the choice (as I see it) is between the current > approach, in which `resolve-dependencies` returns genuine association > lists and the `let*` block turns them JSON objects, or changing > `resolve-dependencies` to return JSON objects and implementing > `json-object-append`, which doesn't seem obviously better, unless it > were part of broader changes.  The return value of resolve-dependencies is okay imo. It's the calling convention that is not. > (As an aside, I am not convinced that the current handling of > "peerDependencies" is right, but I think reevaluating that behavior > is out of scope for this patch series, and particularly for this > patch, in which, as Tim said in  > , my goal was merely to make > the use of `assoc-set!` safe.) I agree that we can ignore the semantics of peerDependencies for now and we may even be able to look aside the use of assoc-set! (although for the purpose of making it easier for the user to rewrite those files on their own as I laid out before, it might still make sense to drop that use regardless, leading by example). > But I think those improvements are out of scope for this patch > series. I don't. Particularly, the current implementation quirks appear to be the sole reason you came up with the solution of #:absent-dependencies, which for the record I still disagree with. We can lay down a better foundation to rewrite JSON data in node-build-system and should export functions that are necessary to do so in build-side code if they're not already part of core guile or other imports. > It seems like much more discussion would be needed on what the > improvements should be, and potentially coordination with other users > of (guix build json). Personally, I'd want to represent JSON objects > with a real immutable dictionary type that gave us more guarantees > about correctness by construction. If we continue with tagged > association lists, we should write a little library of purely > functional operations on JSON objects. But that all seems very far > afield. I'll have to say non sequitur to that. The functionality we require to efficiently rewrite JSON can perfectly be built on top of (a)list primitives and pattern matching, both of which are available to be used in build-side code. We could even throw in SXML if we needed, not that we do. There is really no need to code up yet another set of JSON primitives just to write "hello, world". If you absolutely require it, though: (define json-object->alist cdr) (define (alist->json-object alist) (cons '@ alist)) Magic. Cheers