Re: Announcing emacs-guix-packaging

[zimoun]

Dear,

On Fri, 13 Nov 2020 at 01:28, Ryan Prior <ryanprior@hey.com> wrote:

>> 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.

My English is not good enough to parse « it’s junky ».  Whatever.


> 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.

I am not sure to understand what you mean…

> 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.

…because there is not so much choice: a) interface via the Guix CLI so
invoke ’guix <subcommand>’ via the Emacs ’process-file’ function somehow
and then parse the output *or* b) interface via the Guix scheme API.

You mean that a) would be better, right?  I am not convinced.  Because
the Guix plumbing is Scheme and the Guix CLI is porcelain, there is no
Guix CLI plumbing; contrary to Git, for instance, Magit uses the Git CLI
plumbing (with experiment using libgit2).  IIUC.


> 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.

The point is that emacs-guix is not really maintained these days:

https://github.com/alezost/guix.el/issues/38#issuecomment-617718043


> 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.

[...]

> 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.

If you go that road (CLI+parse output), the first step is to add to Guix
an output formatter.  For example, today “guix package” (i.e., “guix
search” and “guix show”) uses recutils as formatter and sometimes other
formatting (“guix package -A” or “guix package -I” or “guix package -l”).

Basically, other than “package->recutils” (guix/ui.scm) functions should
be added.  Then another option ’--format’ with predefined formats as
’recutils’ (default), oneline, json, free-your-imagination, etc. and
then:

   $ guix search --format=oneline guix
   guix none gnu/packages/package-management.scm:136:4
   emacs-guix 0.5.2-2.58a840d gnu/packages/emacs-xyz.scm:2754:4
   hpcguix-web 0.0.1-5.9de6356 gnu/packages/web.scm:7433:4
   [..]

   $ guix package --format=json -A
   [..]
   {
     "name": "hello",
     "version": "2.10",
     "source": "mirror://gnu/hello/hello-2.10.tar.gz",
     "build-system": "gnu",
     "home-page": "https://www.gnu.org/software/hello/";,
     "synopsis": "Hello, GNU world: An example GNU package",
     "description": "GNU Hello prints a greeting.",
     "license": "GPL-3.0+",
     "native-inputs": ["gettext"]
   }
   [..]

Somehow as “guix describe --format=” already does.


Even we could imagine --format=“%n %v\n%d” with %n, %v, %d representing
say package name, version and inputs; which could mitigate the lack of
CLI plumbing but it seems beyond the initial concern.


All the best,
simon