From: zimoun <zimon.toutoune@gmail.com>
To: "Ryan Prior" <ryanprior@hey.com>, "Ludovic Courtès" <ludo@gnu.org>
Cc: Development of GNU Guix and the GNU System distribution
<guix-devel@gnu.org>
Subject: Re: Announcing emacs-guix-packaging
Date: Fri, 13 Nov 2020 13:31:52 +0100 [thread overview]
Message-ID: <86y2j5e8uf.fsf@gmail.com> (raw)
In-Reply-To: <b0ab7524ec33b251f16aca9fb39451b69e53b045@hey.com>
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
prev parent reply other threads:[~2020-11-13 12:33 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-10 5:07 Announcing emacs-guix-packaging Ryan Prior
2020-11-10 13:30 ` Pierre Neidhardt
2020-11-12 20:53 ` Ludovic Courtès
2020-11-13 1:28 ` Ryan Prior
2020-11-13 9:45 ` Pierre Neidhardt
2020-11-13 13:20 ` zimoun
2020-11-13 14:54 ` John Soo
2020-11-13 16:54 ` Reviving Emacs-Guix Ludovic Courtès
2020-11-13 17:13 ` John Soo
2020-11-13 18:42 ` zimoun
2020-11-16 8:56 ` Ludovic Courtès
2020-11-14 9:42 ` Pierre Neidhardt
2020-11-14 12:57 ` zimoun
2020-11-14 15:59 ` Pierre Neidhardt
2020-11-14 16:56 ` zimoun
2020-11-14 17:30 ` Pierre Neidhardt
2020-11-14 18:40 ` zimoun
2020-11-14 19:15 ` Pierre Neidhardt
2020-11-14 19:52 ` Ricardo Wurmus
2020-11-14 21:29 ` zimoun
2020-11-15 7:37 ` Pierre Neidhardt
2020-11-15 13:15 ` zimoun
2020-11-15 14:11 ` Pierre Neidhardt
2020-11-15 15:23 ` zimoun
2020-11-15 15:45 ` Pierre Neidhardt
2020-11-15 16:05 ` zimoun
2020-11-14 21:11 ` zimoun
2020-11-15 7:53 ` Pierre Neidhardt
2020-11-14 19:49 ` Ricardo Wurmus
2020-11-15 7:36 ` Pierre Neidhardt
2020-11-16 9:02 ` Ludovic Courtès
2020-11-16 9:18 ` Pierre Neidhardt
2020-11-16 12:01 ` zimoun
2020-11-16 12:20 ` Pierre Neidhardt
2020-11-16 12:47 ` zimoun
2020-11-17 7:53 ` Pierre Neidhardt
2020-11-13 12:31 ` zimoun [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86y2j5e8uf.fsf@gmail.com \
--to=zimon.toutoune@gmail.com \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
--cc=ryanprior@hey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).