guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#51838] [PATCH v5 07/45] guix: node-build-system: Add #:absent-depen


From: Philip McGrath
Subject: [bug#51838] [PATCH v5 07/45] guix: node-build-system: Add #:absent-dependencies argument.
Date: Thu, 23 Dec 2021 00:19:57 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1

On 12/21/21 15:44, Liliana Marie Prikler wrote:
Am Dienstag, dem 21.12.2021 um 13:25 -0500 schrieb Philip McGrath:
Here are, to the best of my understanding, the differences in
representation among (guix build json) and the three versions of
guile-json packaged in Guix.
I think the main difference between (guix build json) and guile-json
here are the extended keys in the latter (guix only has strings) and
the vector/object distinction.

For guile-json-4, the representation of the JSON value "null" is also different: #nil vs. the symbol 'null.

I think it'd be rather straight-forward
to write upgrade guidelines in case we ever make the switch.
Similarly, all rules based on pattern-matching *will break*, forcing us
to upgrade all the recipes with it.  WDYT?  Would that be manageable
(assuming the change to require Guile-JSON would already be core-
updates material)?


I actually might like (guix build json) better than guile-json-*! Using vectors for arrays seems roughly awkward as tagged alists, especially if Guile really doesn't have purely functional update procedures for alists---and I sure can't find any---so we'd have to write a little algebra of operations on JSON objects either way. But I'm not really familiar with the pros and cons of each, and I don't know the context behind the previous attempt to switch.

My concern is that someone, or several someones, probably should know all of that context before exposing one representation or another as part of node-build-system's API. As I've said, I think that's a high-priority improvement! But it, and designing nice helper functions, seem quite far removed from the core purpose of this patch series. Since IMO #:absent-dependencies would still be The Right Thing even if those utilities already existed, and since #:absent-dependencies can be implemented without having to resolve any of the broader questions, I think it would be better not to entangle them with this patch series.

Would it mitigate your concerns with #:absent-dependencies at all if I send a separate patch series adding more general utilities based on (guix build json)?

-Philip





reply via email to

[Prev in Thread] Current Thread [Next in Thread]