Re: Announcing emacs-guix-packaging

[Ryan Prior <ryanprior@hey.com>]

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

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

[-- Attachment #2: Type: text/html, Size: 5836 bytes --]