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: Liliana Marie Prikler
Subject: [bug#51838] [PATCH v5 07/45] guix: node-build-system: Add #:absent-dependencies argument.
Date: Thu, 23 Dec 2021 19:12:17 +0100
User-agent: Evolution 3.42.1

Am Donnerstag, dem 23.12.2021 um 00:19 -0500 schrieb Philip McGrath:
> 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.
Different, but configurable, i.e. you can make guile-json-4 return
#nil, which is what would be needed for the sake of compatibility.
> 
> > 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.
I don't think there's been any.  Note that Guix already uses guile-
json, just not at build side.  I don't think there's only one reason
for this; of course we have the incompatibility, but guile-json would
probably also pull in much more into the build than would be needed in
most cases, so that's that.

For the medium/long term I do think guile-json will eventually go the
emacs-json route of making everything about its (de)serialization
configurable, which ought to ease the porting of guix build to it. 
However, pointing at the API stability shield, I don't think we'll be
too hasty porting things over. 

> 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.
You would only have to implement helper functions as needed, i.e. for
now just (with-atomic-json-replacement proc) and (delete-dependencies
json).  My personal interpretation is that read-json/write-json are
already public Guix API and you can easily use them inside node-build-
system as-is (note: you do need to use-modules them, but it doesn't
require building another module closure), but perhaps someone else has
a different reading.

As for other helper functions, that might become useful over time,
those can be added as-needed.

> 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.
I agree, that we can both agree, that whatever we had in mind when
starting this discussion can be implemented without these primitives,
but I disagree on it being The Right Thing.  Particularly, in the case
of #:absent-dependencies, simplicity and completeness are lacking,
whereas in my original suggestion correctness and completeness were
lacking.

For the record, I don't think we can get to The Right Thing without
exposing the JSON somehow.  However, since you argue we can't, we need
to find a course of action, that will allow us to do The Right Thing
later.

I'm sadly a little out of options as I write this, but open to some
suggestions and perhaps I'll get another idea if I gaze at my navel for
some time.

> 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)?
That series would block this one in my opinion (aside from the node
changes, that could be done without it, but we're talking five patches
at most here and I plan to do them over the holidays).  This would
sound like a good idea if you could wait for that discussion to be
resolved, but I fear that's not the case, is it?

Cheers





reply via email to

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