[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#55013: Guix-emacs doesn't work
From: |
Ryan Prior |
Subject: |
bug#55013: Guix-emacs doesn't work |
Date: |
Sat, 25 Mar 2023 21:00:07 +0000 |
------- Original Message -------
On Monday, March 20th, 2023 at 7:09 PM, Ricardo Wurmus <rekado@elephly.net>
wrote:
>
>
> Hi,
>
> this no longer seems to be a problem. Can you please confirm that this
> issue can be closed now?
I can confirm that the emacs-guix package is still broken.
## Steps to reproduce
1. launch Emacs in a container:
$ guix shell -C --no-cwd --expose=/gnu --expose=/var --share=/tmp -E DISPLAY
emacs emacs-guix -- emacs
2. run M-x guix-installed-packages
### Expected result
A list of installed packages should appear.
### Actual result
In *Messages* buffer:
> guix-geiser-eval: Error in evaluating guile expression:
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Unbound variable: %max-returned-list-size
## My Guix version
$ guix --version | grep guix
guix (GNU Guix) 51f8a7aced70b7f79037bd99019dddaea07ced25
## Discussion
When I was working to create an Emacs Guix package
(https://github.com/ryanprior/emacs-guix-packaging) to support my own
workflows, folks were critical of how I run Guix commands in the shell and
parse the output instead of building on the Emacs Guix package and its Guile
REPL approach. But in practice, this package has never worked for me, I always
get REPL errors.
Since then, I have often discussed emacs-guix with other Emacs users in the
community and thus realized I'm far from the only one who's never once got it
to work. Today, despite the efforts of multiple engineers, it remains
reproducibly broken.
My inclination would be to remove entirely the dependency on Geiser and the
Guix REPL, opting instead to connect to a guix-ui service over a stable HTTP
API. The API endpoints would be documented and tested as part of the formal
interface to Guix, and the Emacs package would become a client of that
interface.
Whether you like my alternative or not, do most Guix maintainers have
confidence in the current approach and think emacs-guix just needs a bugfix
here or there, or does anyone else get the impression that it's unsound and
needs a new approach?
Ryan