------- Original Message ------- On Monday, March 20th, 2023 at 7:09 PM, Ricardo Wurmus 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