On November 12, 2020, "Ludovic Courtès" <ludo@gnu.org> wrote:

> Looks nice and useful!



Thank you! If you end up using it, I'd be interested to hear feedback

about what works well and what could go in a different direction.



> Did you consider making it part of Emacs-Guix? That’d give us a single

> go-to place for all things Guix in Emacs.



I don't use emacs-guix myself. I've tried it a couple times but it's

junky. Specifically, it incorporates a lot of custom Guile logic and

depends on internal Guix APIs. This design does not benefit anybody.

It's harmful for the Guix project because having third-party

applications depend on your internal APIs locks you down, where you

can't refactor internal logic without breaking other people's stuff. And

it's sad for users because it exposes them to that routine brokenness,

which in my case has prevented me from ever getting any use out of it

when I've tried it.



And I know I'm not just unlucky: at least once a month we get people in

the IRC or Matrix rooms for Guix who are unable to make emacs-guix work

on their machines. For an interface to Guix, which aims to solve

software deployment problems, this is especially cringe-inducing. It

shows the fundamental weakness of the package's technical design.



So as a result I'm not really interested in contributing to emacs-guix.

I would of course not object if its maintainer wanted to incorporate

parts of my package into theirs. They are both GPLv3.



On the other hand, I am interested in building out a formal API for

tools to interface with Guix without having to depend on its internals

or parse the output of its CLI commands. This could be a Guile API,

although I picture json would be a better choice to support diverse

tooling.



For one example of what I'd want the API for, in my `guix-packaging-

insert-input` command I need to get the list of available Guix packages,

and then for the selected package I need to find its scheme symbol. The

emacs-guix approach to those things is to reach into Guix internal data

structures and read out that data, which doesn't deliver results in

practice. I opt instead to parse the output of the CLI command `guix

package -A ""` as a tsv, which works as long as Guix doesn't change its

output, but that's not guaranteed either.



The format of the output from Guix CLI commands varies quite a lot.

After parsing the tsv from one command, the next step is to find the

corresponding scheme symbol for the chosen package, for which I parse

the output of `guix show <pkg>` but that's not tsv, that's recfile

format. And it doesn't provide the name of the scheme symbol, so I then

go load the source code and look for a `define-public` to scrape the

symbol.



So what I'd want is a uniform scripting interface where I can query Guix

and get responses in a uniform way, whether that's json, recfile, edn,

msgpack, or Guile s-expressions or whatever. Just so it's an explicitly

documented external API that won't change arbitrarily, doesn't freeze

Guix internals, and only requires me to parse one type of output. At

some point in the future I can write more about that, and I'm down to

contribute the labor to make it happen too. We can use this thread as a

kick-off point for that discussion too if you're interested.



But in any case I just wanted to provide some context for why I didn't

build this as an extension to emacs-guix. Hope this helps!



Ryan