Re: Guix Data Service client module

[Christopher Baines <mail@cbaines.net>]

[-- Attachment #1: Type: text/plain, Size: 2401 bytes --]


Ludovic Courtès <ludo@gnu.org> writes:

>> The only thing I can see that's required before merging though is the
>> exports. I'm now thinking about this kind of thing (getting data out of
>> the data service) in the context of patch/branch review.
>
> I think there’s a couple of issues that would be nice to address in the
> JSON API of the data service.
>
> First, it’s unversioned, which will make it hard to maintain things
> going forward.  How about adding, say, “/v1” to URL paths, similar to
> what SWH does?

I think that's a good idea.

> Second, there are places where I found inconsistencies or redundancy in
> the API.  For instance there are several JSON schemas for things called
> “branches” (see the FIXME in there).

Sounds like something to investigate as well.

> The API to access package version history, which I think lots of users
> are interested in, is not intuitive IMO:
>
> scheme@(guile-user)> (define s (open-data-service "https://data.guix.gnu.org"))
> scheme@(guile-user)> (car (package-versions (lookup-package s "emacs")))
> $20 = #<<package-version> string: "27.2" branches: (#<<branch> name: "master" repository-id: 1>)>
> scheme@(guile-user)> (car (package-version-history s (car (package-version-branches $20)) "emacs"))
> $21 = #<<package-version-range> version: "27.2" first-revision: #<<revision> commit: "cc33f50d0e2a7835e99913226cb4c4b0e9e961ae" date: #<date nanosecond: 0 second: 54 minute: 30 hour: 20 day: 25 month: 3 year: 2021 zone-offset: 0>> last-revision: #<<revision> commit: "de38ccf2e0bb2fd21393925c296b65dca7499bd3" date: #<date nanosecond: 0 second: 37 minute: 48 hour: 13 day: 4 month: 2 year: 2022 zone-offset: 0>>>
>
> That said, I don’t have any suggestion on this one.
>
> I also wonder if there’s a way to obtain a commit range for a given
> package version, directly, without having to browse the list returned by
> ‘package-version-history’?

I think the "easy" option is to just add API endpoints for useful
queries, like the one you suggest above.

Though, there's probably some way of providing greater access to the
data. For example, if the data service could populate a tripplestore
with information, you could use SPARQL to query that. I think there's
also other query languages like GraphQL that are designed to address
this kind of problem.

Thanks,

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]