Announcing emacs-guix-packaging

Announcing emacs-guix-packaging

[Ryan Prior]

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

Hi folks! I use Emacs to write and maintain Guix packages, and I've
created some tools and snippets to automate repetitive tasks and remove
guesswork. If you also use Emacs, you might be interested to try them or
contribute your own.

My repository is here: https://github.com/ryanprior/emacs-guix-packaging

To read the elisp file without any non-free JavaScript, use this link:
https://raw.githubusercontent.com/ryanprior/emacs-guix-
packaging/main/guix-packaging.el

I'm calling this my 1.0 release. It's got commands that I'm using daily,
some slick snippet-based workflows for packaging go modules (what I've
been doing a lot of lately,) and documentation. I will continue to
update it and I welcome your feedback and ideas!

I don't have a release on GNU ELPA or Guix yet. Despite helping maintain
a few Emacs packages for some years, this is the first package I've
created myself and set up the infrastructure for, so I'm still figuring
those things out.

Cheers

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

Re: Announcing emacs-guix-packaging

[Pierre Neidhardt]

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

Neat!
I've been waiting for such features for a while!

Time of a Guix package then! ;)

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Announcing emacs-guix-packaging

[Ludovic Courtès]

Hi,

Ryan Prior <ryanprior@hey.com> skribis:

> Hi folks! I use Emacs to write and maintain Guix packages, and I've
> created some tools and snippets to automate repetitive tasks and remove
> guesswork. If you also use Emacs, you might be interested to try them or
> contribute your own.
>
> My repository is here: https://github.com/ryanprior/emacs-guix-packaging
>
> To read the elisp file without any non-free JavaScript, use this link:
> https://raw.githubusercontent.com/ryanprior/emacs-guix-packaging/main/guix-packaging.el
>
> I'm calling this my 1.0 release. It's got commands that I'm using daily,
> some slick snippet-based workflows for packaging go modules (what I've
> been doing a lot of lately,) and documentation. I will continue to
> update it and I welcome your feedback and ideas!

Looks nice and useful!

> I don't have a release on GNU ELPA or Guix yet. Despite helping maintain
> a few Emacs packages for some years, this is the first package I've
> created myself and set up the infrastructure for, so I'm still figuring
> those things out.

Did you consider making it part of Emacs-Guix?  That’d give us a single
go-to place for all things Guix in Emacs.

Thanks for sharing!

Ludo’.

Re: Announcing emacs-guix-packaging

[Ryan Prior]

[-- 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 --]

Re: Announcing emacs-guix-packaging

[Pierre Neidhardt]

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

Hi!

On the one hand, I can only echo Ryan's experience, and I suppose the
experience of most of us: emacs-guix has been a bit broken for a while
now.

I believe it suffers from 2 main issues:

- Geiser is a strong dependency: everything depends from a well-working
  Geiser REPL.

  - Geiser 0.12 broke the REPL setup :(
  - Geiser chokes on large outputs, which happens on any Guix build.  So
    you can't build anything with emacs-guix.

- Emacs-Guix uses private parts of Guix if I'm not mistaken.  Since
  these parts are prone to change, it breaks Emacs-Guix once in a while.

Finally, it seems that Emacs-Guix is mostly unmaintained now:

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

On the other hand, leveraging the actual Guix API is a saner approach
than parsing the output.

It's what I did in Nyxt:

https://github.com/atlas-engineer/nyxt/blob/2-pre-release-4/libraries/ospama/ospama-guix.lisp

It's fast, reliable, flexible, structured.

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

Guix already has a stable API that can be leveraged by any programming
language thanks to the `guix repl` command.  This is what I'm doing in
Nyxt.

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

Maybe emacs-guix does not do it well, but `fold-packages` works well for
Nyxt 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.

Indeed, I don't think this is the right approach :p

Let me know what you think!

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Announcing emacs-guix-packaging

[zimoun]

Hi,

On Fri, 13 Nov 2020 at 10:45, Pierre Neidhardt <mail@ambrevar.xyz> wrote:

> - Emacs-Guix uses private parts of Guix if I'm not mistaken.  Since
>   these parts are prone to change, it breaks Emacs-Guix once in a
>   while.

--8<---------------cut here---------------start------------->8---
$ ag '\(@' --scheme $(guix build emacs-guix -S)
/gnu/store/…-emacs-guix-0.5.2-2.58a840d-checkout/scheme/emacs-guix/actions.scm
200:            ((@@ (guix scripts build) log-url) store file))))))

/gnu/store/…-emacs-guix-0.5.2-2.58a840d-checkout/scheme/emacs-guix/system.scm
55:       ((@@ (gnu system) operating-system-firmware) os)))

/gnu/store/…-emacs-guix-0.5.2-2.58a840d-checkout/scheme/emacs-guix/pack.scm
31:  (map (@@ (guix scripts pack) compressor-name)
32:       (@@ (guix scripts pack) %compressors)))
40:              (@@ (guix scripts pack) %formats)))

/gnu/store/…-emacs-guix-0.5.2-2.58a840d-checkout/scheme/emacs-guix/profiles.scm
123:  (@@ (guix scripts package) search-path-environment-variables))
--8<---------------cut here---------------end--------------->8---

On the other hand, we could ask if these should not be part of the API.
The “(guix scrip <foo>)” seems a good clue. ;-)

From my point of view, your concern is not a real issue here.


> On the other hand, leveraging the actual Guix API is a saner approach
> than parsing the output.
>
> It's what I did in Nyxt:
>
> https://github.com/atlas-engineer/nyxt/blob/2-pre-release-4/libraries/ospama/ospama-guix.lisp

Nice trick!

But using “guix repl” is just a way to avoid to the binding Scheme-Emacs
(or -Common) Lisp, for instance avoid Geiser.  IIUC.

Well, maybe invoking “guix repl” is the fastest way to write plumbing
interfaces avoiding the tough binding.


All the best,
simon

Re: Announcing emacs-guix-packaging

[John Soo]

Hi Zomoun,

zimoun <zimon.toutoune@gmail.com> writes:

> $ ag '\(@' --scheme $(guix build emacs-guix -S)
> /gnu/store/…-emacs-guix-0.5.2-2.58a840d-checkout/scheme/emacs-guix/actions.scm
> 200:            ((@@ (guix scripts build) log-url) store file))))))
>
> /gnu/store/…-emacs-guix-0.5.2-2.58a840d-checkout/scheme/emacs-guix/system.scm
> 55:       ((@@ (gnu system) operating-system-firmware) os)))
>
> /gnu/store/…-emacs-guix-0.5.2-2.58a840d-checkout/scheme/emacs-guix/pack.scm
> 31:  (map (@@ (guix scripts pack) compressor-name)
> 32:       (@@ (guix scripts pack) %compressors)))
> 40:              (@@ (guix scripts pack) %formats)))
>
> /gnu/store/…-emacs-guix-0.5.2-2.58a840d-checkout/scheme/emacs-guix/profiles.scm
> 123:  (@@ (guix scripts package) search-path-environment-variables))
>
> On the other hand, we could ask if these should not be part of the API.
> The “(guix scrip <foo>)” seems a good clue. ;-)
>
> From my point of view, your concern is not a real issue here.

I agree. However I do think those bindings from (guix scripts ...) are
good candidates to be public. Programmatic access to things that cli
users already knows is probably a nice entrypoint for anyone wanting to
start using guix as a scheme library.

I sent patches to expose those bindings: https://issues.guix.gnu.org/44619

> Well, maybe invoking “guix repl” is the fastest way to write plumbing
> interfaces avoiding the tough binding.

Is inferior-lisp an option? Or is it more specifically used for Common
Lisp family lisps?

Thanks,

John

Reviving Emacs-Guix

[Ludovic Courtès]

Hi,

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> I believe it suffers from 2 main issues:
>
> - Geiser is a strong dependency: everything depends from a well-working
>   Geiser REPL.

That’s a feature!

>   - Geiser 0.12 broke the REPL setup :(
>   - Geiser chokes on large outputs, which happens on any Guix build.  So
>     you can't build anything with emacs-guix.

Not a problem if Emacs-Guix were maintained, IMO.  We can talk to each
other, jao (the Geiser maintainer and primary developer) has always been
responsive and helpful.

> - Emacs-Guix uses private parts of Guix if I'm not mistaken.  Since
>   these parts are prone to change, it breaks Emacs-Guix once in a while.

Once upon a time, Emacs-Guix was part of Guix proper, precisely so we
could make sure both stay in sync.  Alex Kost was doing all the work on
Emacs-Guix and decided to maintain it separately in 2016 (commit
deb6276dda81a69da38e842d269c5370a28fa5cf), even though we knew such
problems could arise.  This has worked well for some time, but now it’s
obviously showing its limit.

> Finally, it seems that Emacs-Guix is mostly unmaintained now:
>
> https://github.com/alezost/guix.el/issues/38#issuecomment-617718043

Oh, that’s sad.  :-/

Any Emacser around willing to take care of it at least in “maintenance
mode”?  It seems like fixing the issues we currently have wouldn’t be
too hard.  Then we can tag a release.

I think it would be beneficial longer-term to have the Emacs-Guix repo
in the Guix group on Savannah, from the perspective of Conway’s law¹;
it’s also probably a safe way for the project to deal with contributor
churn.  But if whoever volunteers prefers to maintain it elsewhere, so
be it!

WDYT?

Ludo’.

¹ https://en.wikipedia.org/wiki/Conway%27s_law

Re: Reviving Emacs-Guix

[John Soo]

Hi everyone,

Ludovic Courtès <ludo@gnu.org> writes:

> Any Emacser around willing to take care of it at least in “maintenance
> mode”?  It seems like fixing the issues we currently have wouldn’t be
> too hard.  Then we can tag a release.

I think I can do it. I can't promise a lot of new work but I can at
least fix bugs.

> I think it would be beneficial longer-term to have the Emacs-Guix repo
> in the Guix group on Savannah, from the perspective of Conway’s law¹;
> it’s also probably a safe way for the project to deal with contributor
> churn.  But if whoever volunteers prefers to maintain it elsewhere, so
> be it!

Good idea.

Sounds good to me,

John

Re: Reviving Emacs-Guix

[zimoun]

Hi Ludo,

On Fri, 13 Nov 2020 at 17:54, Ludovic Courtès <ludo@gnu.org> wrote:

> I think it would be beneficial longer-term to have the Emacs-Guix repo
> in the Guix group on Savannah, from the perspective of Conway’s law¹;
> it’s also probably a safe way for the project to deal with contributor
> churn.  But if whoever volunteers prefers to maintain it elsewhere, so
> be it!

[...]

> ¹ https://en.wikipedia.org/wiki/Conway%27s_law

Emacs-Guix is currently on both GitLab and Github; which provide
user-friendly (it depends on your friend ;-)) interface.  One
interesting thing is: how many issue / {M,P}R reported by user that has
not contributed via email-based interface?

I could have wrong but:

 - Jonas Bernoulli about transient instead of magit-popup.
 - Daniel Nagy about imenu integration.
 - 4 people about various issues.


The question is: in this “new” location to have Emacs-Guix on Savannah,
do the multi entry points remain?  Or reduce them to only one, maybe 2?


All the best,
simon

Re: Reviving Emacs-Guix

[Ludovic Courtès]

Hi!

zimoun <zimon.toutoune@gmail.com> skribis:

> The question is: in this “new” location to have Emacs-Guix on Savannah,
> do the multi entry points remain?  Or reduce them to only one, maybe 2?

In practice we received bug reports on bug-guix too—maybe not all of
them, but we definitely got the critical ones.  :-)

If it were me, I’d keep a single point of contact for simplicity and
clarity, but it won’t be me anyway.  ;-)

Ludo’.

Re: Reviving Emacs-Guix

[Pierre Neidhardt]

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

Hi Ludo,

Ludovic Courtès <ludo@gnu.org> writes:

>> I believe it suffers from 2 main issues:
>>
>> - Geiser is a strong dependency: everything depends from a well-working
>>   Geiser REPL.
>
> That’s a feature!

That'd be true if Geiser would indeed help us with Guix.  But here it
actually provides almost no benefits and costs us a lot.

Indeed, the *Guix REPL* buffer

- is not required to build packages,
- does not work to build packages because Geiser chokes on it,
- cannot interrupt some operations (https://gitlab.com/emacs-geiser/geiser/-/issues/11).

The benefits are few as I've experienced them:

- Traces are not interactive, which makes them not so useful:
  https://gitlab.com/emacs-geiser/geiser/-/issues/10

- Guix traces are hard to read anyways (I guess this is mostly due to
  our client / daemon architecture).

> Not a problem if Emacs-Guix were maintained, IMO.  We can talk to each
> other, jao (the Geiser maintainer and primary developer) has always been
> responsive and helpful.

True, the maintainer is responsive, sadly the issues I'm talking about
are hard to solve I think, they've been left hanging for a while now:

- https://gitlab.com/emacs-geiser/geiser/-/issues/9
- https://gitlab.com/emacs-geiser/geiser/-/issues/11

Unless someone wants to roll up their sleeves and fix these, Geiser will
remain a deal-breaker for Emacs-Guix.



I'd like insist: in the current state of Geiser, we cannot leverage it
reliably in Emacs-Guix.  We need to talk to Guix directly, e.g. with
`guix repl` like I've done in Nyxt.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Reviving Emacs-Guix

[zimoun]

Hi Pierre,

On Sat, 14 Nov 2020 at 10:42, Pierre Neidhardt <mail@ambrevar.xyz> wrote:

> That'd be true if Geiser would indeed help us with Guix.  But here it
> actually provides almost no benefits and costs us a lot.
>
> Indeed, the *Guix REPL* buffer
>
> - is not required to build packages,

Is it possible to currently build the packages using Emacs-Guix?

And if you talk about ‘guix-devel-build-package-source‘, it needs before
to ’run-geiser’, I guess.


>> Not a problem if Emacs-Guix were maintained, IMO.  We can talk to each
>> other, jao (the Geiser maintainer and primary developer) has always been
>> responsive and helpful.
>
> True, the maintainer is responsive, sadly the issues I'm talking about
> are hard to solve I think, they've been left hanging for a while now:
>
> - https://gitlab.com/emacs-geiser/geiser/-/issues/9

8 months is bunch of time but not a while. :-)

> - https://gitlab.com/emacs-geiser/geiser/-/issues/11

3 weeks is not a while, neither. ;-)


> I'd like insist: in the current state of Geiser, we cannot leverage it
> reliably in Emacs-Guix.  We need to talk to Guix directly, e.g. with
> `guix repl` like I've done in Nyxt.

For all what “guix-popup” does, maybe pipe to “guix repl” should
simplify.  But I do not see how one could work interactively without
Geiser; for example piping to “guix repl” can not fix your concern about
“Traces are not interactive”, fixing Geiser can.


All the best,
simon

Re: Reviving Emacs-Guix

[Pierre Neidhardt]

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

Hi Simon!

zimoun <zimon.toutoune@gmail.com> writes:

> Is it possible to currently build the packages using Emacs-Guix?
>
> And if you talk about ‘guix-devel-build-package-source‘, it needs before
> to ’run-geiser’, I guess.

Yes, using guix-devel-build-package-source, or even building by writing
Scheme code in the Guix REPL.

>> - https://gitlab.com/emacs-geiser/geiser/-/issues/9
>
> 8 months is bunch of time but not a while. :-)

Actually 9 months, but the issue has been there forever.

The problem is the Schemers are just painfully dealing with the status
quo.  I believe we need to address this.  Geiser is lagging behind by
far, compared to what SLIME, SLY, racket-mode and CIDER can offer.

>> - https://gitlab.com/emacs-geiser/geiser/-/issues/11
>
> 3 weeks is not a while, neither. ;-)

Which 3 weeks?  I think you looked at Maxim's comment :p  The issue was
also opened 9 months ago.

>> I'd like insist: in the current state of Geiser, we cannot leverage it
>> reliably in Emacs-Guix.  We need to talk to Guix directly, e.g. with
>> `guix repl` like I've done in Nyxt.
>
> For all what “guix-popup” does, maybe pipe to “guix repl” should
> simplify.  But I do not see how one could work interactively without
> Geiser; for example piping to “guix repl” can not fix your concern about
> “Traces are not interactive”, fixing Geiser can.

Yes, but my point is that since traces are mostly useless as it is now,
we don't lose any benefit by using `guix repl'.

We have 2 options:

- Fixing Geiser, which might take a long time, leaving us with a broken
  emacs-guix for the time being.
  It's not even clear that it can be done without rewriting everything.

- Or use `guix repl`, which is known to work, already has working code
  out there, and can be deployed in a week or two.

I find the second option more attractive.

We can always go back to Geiser at some point in the future when it gets
more reliable.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Reviving Emacs-Guix

[zimoun]

Hi Pierre,

On Sat, 14 Nov 2020 at 16:59, Pierre Neidhardt <mail@ambrevar.xyz> wrote:
> zimoun <zimon.toutoune@gmail.com> writes:
>
>> Is it possible to currently build the packages using Emacs-Guix?
>>
>> And if you talk about ‘guix-devel-build-package-source‘, it needs before
>> to ’run-geiser’, I guess.
>
> Yes, using guix-devel-build-package-source, or even building by writing
> Scheme code in the Guix REPL.

Maybe I am missing the obvious but how the « pipe to “guix repl” »
approach could be an interactive REPL?


>>> - https://gitlab.com/emacs-geiser/geiser/-/issues/9
>>
>> 8 months is bunch of time but not a while. :-)
>
> Actually 9 months, but the issue has been there forever.

Yes, as any issue before being reported. ;-)


> The problem is the Schemers are just painfully dealing with the status
> quo.  I believe we need to address this.  Geiser is lagging behind by
> far, compared to what SLIME, SLY, racket-mode and CIDER can offer.

I do not understand your point.  You are mixing 2 topics:

 - Emacs front-end for Guix
 - Scheme mode for Emacs

and then applying kind of transitivity: Geiser is poor (compared to
SLIME or SLY) so it cannot be used for Guix at all.  Applying the same
trick: the number of packages in Guix is poor (compared to Debian or
Nix) so Guix cannot be used at all.

If your point is: shared code from « pipe to “guix repl” » could be used
both for an Emacs front-end and a Nyxt one, then maybe… And even I am
not convinced.


>>> - https://gitlab.com/emacs-geiser/geiser/-/issues/11
>>
>> 3 weeks is not a while, neither. ;-)
>
> Which 3 weeks?  I think you looked at Maxim's comment :p  The issue was
> also opened 9 months ago.

Right, I misread. :-)


>> For all what “guix-popup” does, maybe pipe to “guix repl” should
>> simplify.  But I do not see how one could work interactively without
>> Geiser; for example piping to “guix repl” can not fix your concern about
>> “Traces are not interactive”, fixing Geiser can.
>
> Yes, but my point is that since traces are mostly useless as it is now,
> we don't lose any benefit by using `guix repl'.
>
> We have 2 options:
>
> - Fixing Geiser, which might take a long time, leaving us with a broken
>   emacs-guix for the time being.
>   It's not even clear that it can be done without rewriting everything.
>
> - Or use `guix repl`, which is known to work, already has working code
>   out there, and can be deployed in a week or two.
>
> I find the second option more attractive.

You do not convince me.  Because you do not answer to the question: how
one could work interactively without Geiser?  How «pipe to “guix repl”»
could lead to interactive work?  For example, persistence between 2
calls.  And solving that is somehow inheriting from ’comint-mode’ and so
more less rewrite ’geiser-repl.el’; but Guix specific only.  Maybe I am
missing the obvious.

Maybe «pipe to “guix repl”» could simplify what “guix-popup” does.
Even, I am not convinced.

Today, the real issue with Emacs-Guix is not Geiser, at all.  The usage
is often annoying because Emacs-Guix is in low-maintenance mode.


Well, at the end, the only judge is the effective code. ;-)

Cheers,
simon

Re: Reviving Emacs-Guix

[Pierre Neidhardt]

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

To answer all your points: `guix repl` woud only be used for queries,
not for transactions.

For the latter, sending shell crafted commands have worked well for me.
They can be sent to an M-x shell, Vterm or Eshell buffer.

Example: the user wants to build Emacs?
Make a dedicated "M-x shell" buffer and send "guix build emacs" there.

The great benefit is that the user is in a familiar environment and can
do stuff like "C-c C-c"

>> Actually 9 months, but the issue has been there forever.
>
> Yes, as any issue before being reported. ;-)

No, sometimes issue appear after features are implemented, or after
regressions.

It's not the case here: these issues exist since the beginning of
Geiser.
It's important, because it highlights design flaws.

> I do not understand your point.  You are mixing 2 topics:
>
>  - Emacs front-end for Guix
>  - Scheme mode for Emacs

I don't want to mix the 2, emacs-guix does.

I'm suggesting precisely this: don't mix up the Schemer environment with
emacs-guix because of the load of trouble it brings in.

> and then applying kind of transitivity: Geiser is poor (compared to
> SLIME or SLY) so it cannot be used for Guix at all.  Applying the same
> trick: the number of packages in Guix is poor (compared to Debian or
> Nix) so Guix cannot be used at all.

This is not what I'm saying ;)

>> We have 2 options:
>>
>> - Fixing Geiser, which might take a long time, leaving us with a broken
>>   emacs-guix for the time being.
>>   It's not even clear that it can be done without rewriting everything.
>>
>> - Or use `guix repl`, which is known to work, already has working code
>>   out there, and can be deployed in a week or two.
>>
>> I find the second option more attractive.
>
> You do not convince me.  Because you do not answer to the question: how
> one could work interactively without Geiser?  How «pipe to “guix repl”»
> could lead to interactive work?

See above.

> For example, persistence between 2
> calls.

emacs-guix never relies on persistence if I'm not mistaken.

My suggestion indeed lacks persistence, but at least it works for now
until we figure out something better.

> And solving that is somehow inheriting from ’comint-mode’ and so
> more less rewrite ’geiser-repl.el’; but Guix specific only.  Maybe I am
> missing the obvious.

Sorry I didn't get this part.

> Maybe «pipe to “guix repl”» could simplify what “guix-popup” does.
> Even, I am not convinced.

Not just that, but listing packages, package details, output listing,
profile listing, generation listing, etc.

Try it out in Nyxt, you'll see for yourself :)

> Today, the real issue with Emacs-Guix is not Geiser, at all.

Emacs-Guix can't install a package a package that needs to be built
because of Geiser.  So yes, Geiser is the issue.

> Well, at the end, the only judge is the effective code. ;-)

I have a proof of concept that works :)

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Reviving Emacs-Guix

[zimoun]

Hi Pierre,

I do not understand your arguments.  Even re-reading all the thread.

On one hand you are saying that Geiser is the issue of Emacs-Guix.  You
raise issue with build (which ’guix-popup’ does not do).  And issues
about Geiser proper, compared to SLY or SLIME, and Geiser allows to work
interactively (*Guix REPL*).

On the other hand, you say that « pipe to “guix repl” » would not tackle
the issues you raise about interactive-ness.


> To answer all your points: `guix repl` woud only be used for queries,
> not for transactions.

AFAIU, guix-popup already does that.

The annoyance that popups time to time are not related to Geiser but
related the low-maintenance mode.  IMHO.


> For the latter, sending shell crafted commands have worked well for me.
> They can be sent to an M-x shell, Vterm or Eshell buffer.
>
> Example: the user wants to build Emacs?
> Make a dedicated "M-x shell" buffer and send "guix build emacs" there.

Euh?  You can do the same with anything.  Simply use something else.
I do not understand.


>> I do not understand your point.  You are mixing 2 topics:
>>
>>  - Emacs front-end for Guix
>>  - Scheme mode for Emacs
>
> I don't want to mix the 2, emacs-guix does.
>
> I'm suggesting precisely this: don't mix up the Schemer environment with
> emacs-guix because of the load of trouble it brings in.
>
>> and then applying kind of transitivity: Geiser is poor (compared to
>> SLIME or SLY) so it cannot be used for Guix at all.  Applying the same
>> trick: the number of packages in Guix is poor (compared to Debian or
>> Nix) so Guix cannot be used at all.
>
> This is not what I'm saying ;)

What are the issues of Geiser that are blocking in guix-popup?


>> For example, persistence between 2
>> calls.
>
> emacs-guix never relies on persistence if I'm not mistaken.

M-x guix-switch-to-repl


> My suggestion indeed lacks persistence, but at least it works for now
> until we figure out something better.

Now you convinced me that Emacs-Guix needs love.  Well the “it works” in
« at least it works for now » is meaningless for me so instead I am
going to report what Emacs-Guix fails and what I would like to have.  It
will be more fruitful. ;-)


>> And solving that is somehow inheriting from ’comint-mode’ and so
>> more less rewrite ’geiser-repl.el’; but Guix specific only.  Maybe I am
>> missing the obvious.
>
> Sorry I didn't get this part.

You are taking the part that more or less works in Emacs-Guix and want
to replace it.  And the other part which is more broken, you remove it.


>> Maybe «pipe to “guix repl”» could simplify what “guix-popup” does.
>> Even, I am not convinced.
>
> Not just that, but listing packages, package details, output listing,
> profile listing, generation listing, etc.

I do not know which version of Emacs-Guix you are using but all that is
already available.  For example,

   M-x guix-popup p L bro RET C-s ny RET RET
   M-x guix-popup p N yxt$ RET
   M-x guix-popup P a
   M-x guix-popop P a
   M-x guix-popop P l 2 RET

etc.  And it works!

There is still room of improvements, though. :-)
And others are broken, for instance:

   M-x guix-popup c
   

> Try it out in Nyxt, you'll see for yourself :)

You know that I am trying Nyxt time to time. :-)

However, I am not convinced that on your side you are trying Emacs-Guix
to see for yourself. ;-)


>> Today, the real issue with Emacs-Guix is not Geiser, at all.
>
> Emacs-Guix can't install a package a package that needs to be built
> because of Geiser.  So yes, Geiser is the issue.

The dirty-fix in the kind of “guix repl” fashion is easy: run
“(guix-build args)” and expose the output in a specific buffer.
Whatever.


Thank you for sharing your views.  Now I am convinced that Emacs-Guix
needs love. :-)

Cheers,
simon

Re: Reviving Emacs-Guix

[Pierre Neidhardt]

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

Indeed, lots of misunderstandings in here.

I think it's because we are not talking about the same use cases of
Emacs-Guix.

The main issue I was talking about (there are many other issues indeed)
is that of _installing and building packages_ from Emacs Guix.

Run guix-devel-build-package-definition on a package definition.  If no
substitute is available, it will try to build the package in a REPL.  If
the build output is too long (happens very often!) it will choke Geiser.

WARNING: this might hang your emacs ;)

Does that make more sense?

> On one hand you are saying that Geiser is the issue of Emacs-Guix.  You
> raise issue with build (which ’guix-popup’ does not do).

`guix-popup` is only one of the many functions of emacs-guix.  I was not
talking about it.

> And issues about Geiser proper, compared to SLY or SLIME, and Geiser
> allows to work interactively (*Guix REPL*).

Misunderstanding: many emacs-guix commands run stuff in the *Guix REPL*
for the user.  (E.g. guix-devel-build-package-definition.)

I was not talking about the user interactive themselves with the
*Guix REPL*.  I think that's the confusion ;)

> On the other hand, you say that « pipe to “guix repl” » would not tackle
> the issues you raise about interactive-ness.

Indeed, I was not talking about REPL interactivity.

>> To answer all your points: `guix repl` woud only be used for queries,
>> not for transactions.
>
> AFAIU, guix-popup already does that.
>
> The annoyance that popups time to time are not related to Geiser but
> related the low-maintenance mode.  IMHO.

Add a breakpoint to `guix-geiser-eval`, you'll see.  Almost every
emacs-guix command depends on it.

Geiser is at the lowest level of all of Emacs-Guix.

>> Example: the user wants to build Emacs?
>> Make a dedicated "M-x shell" buffer and send "guix build emacs" there.
>
> Euh?  You can do the same with anything.  Simply use something else.
> I do not understand.

Hmm?  Why would I use something else?

To be more explicit, the "build packages passed as argument" could be
implemented by popping up a shell buffer and automatically executing

--8<---------------cut here---------------start------------->8---
$ guix install package-1 package-2...
--8<---------------cut here---------------end--------------->8---

in it.  In short, use `M-x shell` or equivalent instead of Geiser.

> What are the issues of Geiser that are blocking in guix-popup?

Try building a package as I suggested in the beginning.

>> emacs-guix never relies on persistence if I'm not mistaken.
>
> M-x guix-switch-to-repl

This is not persistence that's needed for the emacs-guix commands.

The commands to list generations, package info, etc. do no need
persistence.

>> My suggestion indeed lacks persistence, but at least it works for now
>> until we figure out something better.
>
> Now you convinced me that Emacs-Guix needs love.  Well the “it works” in
> « at least it works for now » is meaningless for me

Why?  A program that works is meaningful I believe.

> so instead I am going to report what Emacs-Guix fails and what I would
> like to have.  It will be more fruitful. ;-)

I've reported some of the issues, and I've concluded that some of them
would be resolved by not using Geiser to talk to Guix.

Of course fixing Geiser is an option, but it's a very rough road to take
I believe.

>>> And solving that is somehow inheriting from ’comint-mode’ and so
>>> more less rewrite ’geiser-repl.el’; but Guix specific only.  Maybe I am
>>> missing the obvious.
>>
>> Sorry I didn't get this part.
>
> You are taking the part that more or less works in Emacs-Guix and want
> to replace it.  And the other part which is more broken, you remove it.

I think there is a misunderstanding.

Build a package does not work in Emacs Guix, and this is what I want
to fix, among other things.

I don't want to remove any feature from Emacs Guix.

For instance, we can keep the feature "switch to a Geiser REPL", while
at the same time not having _all_ actions depend on Geiser.

To sum up:

- Everything that needs Geiser (like "switch to REPL"), we keep.
- Everything else can use `guix repl` or direct shell invokations.

>>> Maybe «pipe to “guix repl”» could simplify what “guix-popup” does.
>>> Even, I am not convinced.
>>
>> Not just that, but listing packages, package details, output listing,
>> profile listing, generation listing, etc.
>
> I do not know which version of Emacs-Guix you are using but all that is
> already available.  For example,
>
>    M-x guix-popup p L bro RET C-s ny RET RET
>    M-x guix-popup p N yxt$ RET
>    M-x guix-popup P a
>    M-x guix-popop P a
>    M-x guix-popop P l 2 RET
>
> etc.  And it works!

Try guix-devel-build-package-definition ;)


>> Emacs-Guix can't install a package a package that needs to be built
>> because of Geiser.  So yes, Geiser is the issue.
>
> The dirty-fix in the kind of “guix repl” fashion is easy: run
> “(guix-build args)” and expose the output in a specific buffer.
> Whatever.

It won't work, because the user must be able to interrupt the process.
So instead of re-inventing the wheel, it's better to let an Emacs mode
that already support process interruption do the job.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Reviving Emacs-Guix

[Ricardo Wurmus]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Build a package does not work in Emacs Guix, and this is what I want
> to fix, among other things.

If that’s the only thing then this is an easy fix: avoid the REPL for
just this command for now.

> I don't want to remove any feature from Emacs Guix.
>
> For instance, we can keep the feature "switch to a Geiser REPL", while
> at the same time not having _all_ actions depend on Geiser.
>
> To sum up:
>
> - Everything that needs Geiser (like "switch to REPL"), we keep.
> - Everything else can use `guix repl` or direct shell invokations.

Right.

I think that “guix build” is still a thing that could be done in the
REPL (on arbitrary package values that may not exist in any file), but I
suppose this could be done with “guix repl” one way or another.

-- 
Ricardo

Re: Reviving Emacs-Guix

[zimoun]

Hi Pierre,

On Sat, 14 Nov 2020 at 20:52, Ricardo Wurmus <rekado@elephly.net> wrote:
> Pierre Neidhardt <mail@ambrevar.xyz> writes:
>
>> Build a package does not work in Emacs Guix, and this is what I want
>> to fix, among other things.
>
> If that’s the only thing then this is an easy fix: avoid the REPL for
> just this command for now.

Could you try this and tell if Emacs hangs?  On my laptop, the first
attempts are not so worse.  M-x ielm

--8<---------------cut here---------------start------------->8---
*** Welcome to IELM ***  Type (describe-mode) for help.
ELISP> (require 'guix-repl)
guix-repl
ELISP> (guix-eval-in-repl ",use(guix scripts build)")
nil
ELISP> (guix-eval-in-repl "(guix-build \"nyxt\" \"--no-grafts\" \"--check\")")
nil
--8<---------------cut here---------------end--------------->8---

Cheers,
simon

Re: Reviving Emacs-Guix

[Pierre Neidhardt]

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

Morning Zimoun!

zimoun <zimon.toutoune@gmail.com> writes:

> Could you try this and tell if Emacs hangs?  On my laptop, the first
> attempts are not so worse.  M-x ielm
>
> --8<---------------cut here---------------start------------->8---
> *** Welcome to IELM ***  Type (describe-mode) for help.
> ELISP> (require 'guix-repl)
> guix-repl
> ELISP> (guix-eval-in-repl ",use(guix scripts build)")
> nil
> ELISP> (guix-eval-in-repl "(guix-build \"nyxt\" \"--no-grafts\" \"--check\")")
> nil
> --8<---------------cut here---------------end--------------->8---

Maybe a misunderstanding, but comint-mode is not the problem here, it
works very well indeed with big outputs.
Only Geiser chokes on it.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Reviving Emacs-Guix

[zimoun]

Hi Pierre,

On Sun, 15 Nov 2020 at 08:37, Pierre Neidhardt <mail@ambrevar.xyz> wrote:
> zimoun <zimon.toutoune@gmail.com> writes:
>
>> Could you try this and tell if Emacs hangs?  On my laptop, the first
>> attempts are not so worse.  M-x ielm
>>
>> --8<---------------cut here---------------start------------->8---
>> *** Welcome to IELM ***  Type (describe-mode) for help.
>> ELISP> (require 'guix-repl)
>> guix-repl
>> ELISP> (guix-eval-in-repl ",use(guix scripts build)")
>> nil
>> ELISP> (guix-eval-in-repl "(guix-build \"nyxt\" \"--no-grafts\" \"--check\")")
>> nil
>> --8<---------------cut here---------------end--------------->8---
>
> Maybe a misunderstanding, but comint-mode is not the problem here, it
> works very well indeed with big outputs.
> Only Geiser chokes on it.

I do not understand your point.  ’guix-eval-in-repl’ is a wrapper around
’geiser-repl--send’ so it uses Geiser, isn’t it?

From my understanding, the culprit of Emacs hanging when building seems
more something wrong with the current implementation in Emacs-Guix than
really Geiser.

It reads:

    (guix-eval-in-repl
     (format (concat "(build-package* (package-by-id %d)"
                     " #:use-substitutes? %s"
                     " #:dry-run? %s)")

where ’build-packages*’ reads:

--8<---------------cut here---------------start------------->8---
(define (build-package* package . build-options)
  "Build PACKAGE using BUILD-OPTIONS acceptable by 'set-build-options'.
Show what and how will/would be built."
  (with-store store
    (run-with-store store
      (apply build-package package build-options))))
--8<---------------cut here---------------end--------------->8---

Especially if

     (guix-eval-in-repl
       "(guix-build \"nyxt\" \"--no-grafts\" \"--check\")")

works fine.


All the best,
simon


PS:
What do you name Geiser?

Re: Reviving Emacs-Guix

[Pierre Neidhardt]

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

zimoun <zimon.toutoune@gmail.com> writes:

>> Maybe a misunderstanding, but comint-mode is not the problem here, it
>> works very well indeed with big outputs.
>> Only Geiser chokes on it.
>
> I do not understand your point.  ’guix-eval-in-repl’ is a wrapper around
> ’geiser-repl--send’ so it uses Geiser, isn’t it?

Oops, sorry, I was focused on the IELM part, I though you were
outputting in the IELM buffer!

My bad, makes sense now.

> Especially if
>
>      (guix-eval-in-repl
>        "(guix-build \"nyxt\" \"--no-grafts\" \"--check\")")
>
> works fine.

What do you mean with this part?

> PS:
> What do you name Geiser?

Sorry, I don't understand your question :p

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Reviving Emacs-Guix

[zimoun]

On Sun, 15 Nov 2020 at 15:11, Pierre Neidhardt <mail@ambrevar.xyz> wrote:

> My bad, makes sense now.

If it makes sense…

>> Especially if
>>
>>      (guix-eval-in-repl
>>        "(guix-build \"nyxt\" \"--no-grafts\" \"--check\")")
>>
>> works fine.
>
> What do you mean with this part?

… I mean replace the current offending part:

    (guix-eval-in-repl
     (format (concat "(build-package* (package-by-id %d)"
                     " #:use-substitutes? %s"
                     " #:dry-run? %s)")
             package-id
             (guix-guile-boolean guix-use-substitutes)
             (guix-guile-boolean guix-dry-run)))))

by something like:

    (guix-eval-in-repl
     (format (concat "(guix-build \"%s\" \"%s")
             package-name
             some-options)

in the Emacs function ’guix-build-package’ which is the one that chokes
the build part of Emacs-Guix.  Then this ’guix-build-package’ function
has to be exposed to ’M-x’, currently not and I do not why.

Somehow replace/rewrite ’build-packages*’ which seems the offender.  Not
Geiser.  If you confirm that it works for you in *ielm*.

The function ’guix-devel-build-package-source’ is another story because
it means interactive-ness.  Well, I have not looked into.  But similar
trick could be used.

Cheers,
simon

Re: Reviving Emacs-Guix

[Pierre Neidhardt]

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

Good stuff!
Can you report your findings on the GitLab repo of emacs-guix?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Reviving Emacs-Guix

[zimoun]

On Sun, 15 Nov 2020 at 16:45, Pierre Neidhardt <mail@ambrevar.xyz> wrote:
> Good stuff!

I do not know but you aroused me about Geiser. ;-)

> Can you report your findings on the GitLab repo of emacs-guix?

I could.  Even send a patch.  :-)

Once the future of Emacs-Guix is a bit more clear.

All the best,
simon

Re: Reviving Emacs-Guix

[zimoun]

Hi Pierre,

On Sat, 14 Nov 2020 at 20:15, Pierre Neidhardt <mail@ambrevar.xyz> wrote:
> Indeed, lots of misunderstandings in here.

[...]

> Run guix-devel-build-package-definition on a package definition.

Indeed, miscommunication here.  From my understanding the key point of
’guix-devel-build-package-definition’ is to be interactive at the REPL
level.  What you mean, I am guessing, is the « Build » button which
calls ’guix-build-package’.

This latter function is not reachable by M-x and should be.  Another
story. :-)

I agree that building is an issue because of Geiser.  As I previously
said and as Ricardo said too, here ’guix-eval-in-repl’ could be
by-passed. 

Note that I agree with you and on the Ryan’s comment that sometimes it
is a bit a mess: the Emacs “guix-build-package” function uses the Scheme
function ’build-package*’ defined by Emacs-Guix which looks to me
awkward: the nested reads,

   (with-store store
     (run-with-store store
       …))

simply calling “build-package” from Guix proper.

Well, again another story.  Love is missing.


>> On one hand you are saying that Geiser is the issue of Emacs-Guix.  You
>> raise issue with build (which ’guix-popup’ does not do).
>
> `guix-popup` is only one of the many functions of emacs-guix.  I was not
> talking about it.

About which one are you talking?  Except “build” that we already
discussed above.


>> And issues about Geiser proper, compared to SLY or SLIME, and Geiser
>> allows to work interactively (*Guix REPL*).
>
> Misunderstanding: many emacs-guix commands run stuff in the *Guix REPL*
> for the user.  (E.g. guix-devel-build-package-definition.)
>
> I was not talking about the user interactive themselves with the
> *Guix REPL*.  I think that's the confusion ;)

That’s a feature as Ludo and Ricardo said. From my opinion too.

What’s wrong with the sequence:

  M-x guix p n emacs-paredit
  ;; Click on Build button
  M-x guix-switch-to-repl
  ;; Fix the issue with ,use(emacs-guix packages)
  M-x guix p n nyxt
  ;; Click the Size button

And then later, “M-x guix-switch-to-repl“ and I get:

--8<---------------cut here---------------start------------->8---
GNU Guile 3.0.4
Copyright (C) 1995-2020 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> ,m (emacs-guix)
scheme@(emacs-guix)> (build-package* (package-by-id 140548324139648) #:use-substitutes? #t #:dry-run? #t)
;;; <stdin>:5:16: warning: possibly unbound variable `package-by-id'
ice-9/boot-9.scm:1669:16: In procedure raise-exception:
error: package-by-id: unbound variable

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(emacs-guix) [1]> ,q
scheme@(emacs-guix)> ,use(emacs-guix packages)
scheme@(emacs-guix)> (build-package* (package-by-id 140548324139648) #:use-substitutes? #t #:dry-run? #t)
/gnu/store/1wb8yinahw2xqmf8cksg6kmrmapxjl6l-emacs-paredit-24
$4 = #t
scheme@(emacs-guix)> (guix-command "size" "emacs-paredit@24")
store item                                                       total    self
/gnu/store/1wb8yinahw2xqmf8cksg6kmrmapxjl6l-emacs-paredit-24         0.2     0.2 100.0%
total: 0.2 MiB
$5 = #t
scheme@(emacs-guix)> (guix-command "size" "nyxt@2-pre-release-3")
store item                                                       total    self
/gnu/store/118xpdazyylxa1rlc68h9lmh38vhxrb4-llvm-10.0.0            210.8   139.3   9.8%
/gnu/store/1qmd9achfkm1njzxf8hi86q53pmy9sxk-mesa-20.0.7            369.2   131.3   9.2%
/gnu/store/pk2802k343mcy0wy9g9spf4l8lv2a099-nyxt-2-pre-release-3  1426.1   123.4   8.7%
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0              178.5   107.3   7.5%
/gnu/store/pw5z61sdvclw9v1bprylsqrjf2m1f941-webkitgtk-2.30.1       964.6   102.9   7.2%

[...]

/gnu/store/3zdvikziccm9adhvvynddj2ar336bxq7-cl-trivial-file-size-0.0.0-0.1c1d672     0.0     0.0   0.0%
/gnu/store/7hvl7cwhjk1anwpwjh9wh7n29799yi7m-cl-trivial-macroexpand-all-0.0.0-0.933270a     0.0     0.0   0.0%
total: 1426.1 MiB
$6 = #t
scheme@(emacs-guix)>
--8<---------------cut here---------------end--------------->8---


> To be more explicit, the "build packages passed as argument" could be
> implemented by popping up a shell buffer and automatically executing
>
> --8<---------------cut here---------------start------------->8---
> $ guix install package-1 package-2...
> --8<---------------cut here---------------end--------------->8---
>
> in it.  In short, use `M-x shell` or equivalent instead of Geiser.

Ok, but that the same story as ’build’.  Right?


>>> emacs-guix never relies on persistence if I'm not mistaken.
>>
>> M-x guix-switch-to-repl
>
> This is not persistence that's needed for the emacs-guix commands.

Wait, you said « emacs-guix never relies on persistence if I'm not
mistaken. » which is wrong because everything is sent to *Guix REPL*
(Geiser) reachable with “M-x guix-switch-to-repl“ as shown above.


> The commands to list generations, package info, etc. do no need
> persistence.

That’s another story.  Maybe you have right and some actions of
Emacs-Guix should run differently than with ‘guix-eval-in-repl’.


>>> My suggestion indeed lacks persistence, but at least it works for now
>>> until we figure out something better.
>>
>> Now you convinced me that Emacs-Guix needs love.  Well the “it works” in
>> « at least it works for now » is meaningless for me
>
> Why?  A program that works is meaningful I believe.

Which program are you talking about?


>> so instead I am going to report what Emacs-Guix fails and what I would
>> like to have.  It will be more fruitful. ;-)
>
> I've reported some of the issues, and I've concluded that some of them
> would be resolved by not using Geiser to talk to Guix.

Maybe.  It should be addressed action by action.  Instead of thrashing
Geiser.  IMHO.


> Build a package does not work in Emacs Guix, and this is what I want
> to fix, among other things.

I got it about the build and install parts. :-D

What are the « among other things »?


All the best,
simon

Re: Reviving Emacs-Guix

[Pierre Neidhardt]

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

zimoun <zimon.toutoune@gmail.com> writes:

>> `guix-popup` is only one of the many functions of emacs-guix.  I was not
>> talking about it.
>
> About which one are you talking?  Except “build” that we already
> discussed above.

I've raised mostly 2 issues in this conversation, the ones I've
mentioned on GitLab, sorry if that was unclear :)

- https://gitlab.com/emacs-geiser/geiser/-/issues/9
  Geiser chokes on big outputs, so guix-devel-build-package-definition
  is not usable.

  Proposed solution: Use a non-Geiser comint mode like IELM or M-x
  shell.
  Or Eshell (not a comint-mode though).

- https://gitlab.com/emacs-geiser/geiser/-/issues/11

  This one can seriously hang your Emacs when calling
  `geiser-mode-switch-to-repl-and-enter` from a .scm of an
  not-fully-built Guix.

  I remember hitting this issue with emacs-guix, but I can't remember a
  recipe.
  So maybe this has nothing to do with emacs-guix after all, but let's
  keep it in mind in case it comes up again.


Then I remembered another one:

- https://gitlab.com/emacs-guix/emacs-guix/-/issues/8

  It's unclear to me whether this one is due to Geiser or not.
  I can still reproduce it today.

> That’s a feature as Ludo and Ricardo said. From my opinion too.
>
> What’s wrong with the sequence:

Nothing wrong!

> Ok, but that the same story as ’build’.  Right?

Yes.

>> This is not persistence that's needed for the emacs-guix commands.
>
> Wait, you said « emacs-guix never relies on persistence if I'm not
> mistaken. » which is wrong because everything is sent to *Guix REPL*
> (Geiser) reachable with “M-x guix-switch-to-repl“ as shown above.

It does not _rely_ on it, in the sense that it's not necessary, it could
work very well without it.

>>>> My suggestion indeed lacks persistence, but at least it works for now
>>>> until we figure out something better.
>>>
>>> Now you convinced me that Emacs-Guix needs love.  Well the “it works” in
>>> « at least it works for now » is meaningless for me
>>
>> Why?  A program that works is meaningful I believe.
>
> Which program are you talking about?

Helm-System-Packages and Nyxt are 2 example programs that can talk to
Guix reliably.

Not saying we should use them instead, of course.
But this technique is worth exploring to make Emacs-Guix more reliable.

> Maybe.  It should be addressed action by action.  Instead of thrashing
> Geiser.  IMHO.

I didn't mean to thrash (or did you mean "trash"?) Geiser, sorry if that
came across this way.

I just wanted to highlight some hard-to-fix (design?) issue with Geiser
that come in the way of Emacs-Guix, so _in the context of Emacs Guix_, I
believe that leveraging other means of communicating with Guix can be a
good idea, at least for some operations like building packages.

> What are the « among other things »?

For instance:

- https://gitlab.com/emacs-guix/emacs-guix/-/merge_requests/8

- Channels support
  https://gitlab.com/emacs-guix/emacs-guix/-/issues/17

The above has nothing to do with Geiser of course, as you
said, the fix is love! :)

Cheers!

--
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Reviving Emacs-Guix

[Ricardo Wurmus]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> I'd like insist: in the current state of Geiser, we cannot leverage it
> reliably in Emacs-Guix.  We need to talk to Guix directly, e.g. with
> `guix repl` like I've done in Nyxt.

I don’t know.  Geiser is pretty neat.  I like that I can send anything
from a Guix source buffer to the REPL and invoke Guix commands on them.
This close interaction between the evaluated source and Guix actions
blurs the line between what is flexible code and what is the cold and
clunky shell environment.  Using Geiser is a feature.

Invoking mere shell snippets isn’t quite as interesting.

-- 
Ricardo

Re: Reviving Emacs-Guix

[Pierre Neidhardt]

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

Ricardo Wurmus <rekado@elephly.net> writes:

> I don’t know.  Geiser is pretty neat.  I like that I can send anything
> from a Guix source buffer to the REPL and invoke Guix commands on them.
> This close interaction between the evaluated source and Guix actions
> blurs the line between what is flexible code and what is the cold and
> clunky shell environment.  Using Geiser is a feature.
>
> Invoking mere shell snippets isn’t quite as interesting.

True, let's use Geiser where we can.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Reviving Emacs-Guix

[Ludovic Courtès]

Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

> Pierre Neidhardt <mail@ambrevar.xyz> writes:
>
>> I'd like insist: in the current state of Geiser, we cannot leverage it
>> reliably in Emacs-Guix.  We need to talk to Guix directly, e.g. with
>> `guix repl` like I've done in Nyxt.

Geiser could/should start ‘guix repl’ instead of ‘guile’ as its entry
point.

> I don’t know.  Geiser is pretty neat.  I like that I can send anything
> from a Guix source buffer to the REPL and invoke Guix commands on them.
> This close interaction between the evaluated source and Guix actions
> blurs the line between what is flexible code and what is the cold and
> clunky shell environment.  Using Geiser is a feature.
>
> Invoking mere shell snippets isn’t quite as interesting.

+1

It was a conscious design choice to have tight integration via the
Scheme APIs rather than by wrapping the command-line interface, and I
think it’s worked well.

The development features (info "(emacs-guix) Development") also
obviously benefit from that.

Thanks,
Ludo’.

Re: Reviving Emacs-Guix

[Pierre Neidhardt]

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

Ludovic Courtès <ludo@gnu.org> writes:

> It was a conscious design choice to have tight integration via the
> Scheme APIs rather than by wrapping the command-line interface, and I
> think it’s worked well.
>
> The development features (info "(emacs-guix) Development") also
> obviously benefit from that.

Sadly it's the part that exposes one of the most obvious issues:
guix-devel-build-package-definition ("C-c . b") chokes Geiser and hangs
Emacs.

Obviously, having a REPL would be fantastic.  But I don't know how to
fix these issues with Geiser, it seems pretty tough.

For the lack of a better option, building outside Geiser seems to be a
sane fix.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Reviving Emacs-Guix

[zimoun]

Hi,

On Mon, 16 Nov 2020 at 10:18, Pierre Neidhardt <mail@ambrevar.xyz> wrote:
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> It was a conscious design choice to have tight integration via the
>> Scheme APIs rather than by wrapping the command-line interface, and I
>> think it’s worked well.
>>
>> The development features (info "(emacs-guix) Development") also
>> obviously benefit from that.
>
> Sadly it's the part that exposes one of the most obvious issues:
> guix-devel-build-package-definition ("C-c . b") chokes Geiser and hangs
> Emacs.

First, please Pierre, could you stop to refer to
`guix-devel-build-package-definition' when the correct one is
`guix-build-package'; which needs some updates, I agree.  Patch should
come…

Second, the issues with building packages using Emacs-Guix are about
implementation details i.e., fix the use of the API.  I am still missing
why Geiser chokes when “guix repl” in ’M-x shell’ do not since they are
both inherited from `comint-mode'.  It definitively looks like a misuse
of the Guix’s API.  IMHO.

Last, I agree that the general design should use the Scheme’s API rather
than wrapping the command-line interface.  However, worse is better and
maybe it could do the trick for some very specific case (build for
instance).


All the best,
simon

Re: Reviving Emacs-Guix

[Pierre Neidhardt]

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

zimoun <zimon.toutoune@gmail.com> writes:

>> Sadly it's the part that exposes one of the most obvious issues:
>> guix-devel-build-package-definition ("C-c . b") chokes Geiser and hangs
>> Emacs.
>
> First, please Pierre, could you stop to refer to
> `guix-devel-build-package-definition' when the correct one is
> `guix-build-package'; which needs some updates, I agree.  Patch should
> come…

Misunderstanding?  guix-devel-build-package-definition is an actual
command, why do you think this is incorrect?   Are you talking about
something else?

Maybe I'm reading you wrong, but your last paragraph reads a bit brash.
Let's keep this a friendly conversation! :)

> Second, the issues with building packages using Emacs-Guix are about
> implementation details i.e., fix the use of the API.  I am still missing
> why Geiser chokes when “guix repl” in ’M-x shell’ do not since they are
> both inherited from `comint-mode'.

It's partly explored here: https://gitlab.com/emacs-geiser/geiser/-/issues/9

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Reviving Emacs-Guix

[zimoun]

Hi Pierre,

> Maybe I'm reading you wrong, but your last paragraph reads a bit brash.
> Let's keep this a friendly conversation! :)

I am sorry if it does not look friendly.  It was not my intention.
Apologies if I used incorrect words.


For the other questions, well, if we look at the tree of this thread, we
had already a long discussion. :-) So I am going to implement a first
draft of something and then we will have a basis to discuss further
because somehow we need a mean to reduce the miscommunication we seem
to have; since we cannot go for a drink together. ;-)

Cheers,
simon

Re: Reviving Emacs-Guix

[Pierre Neidhardt]

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

No worries ;)

Happy bug-hunting, let's make emacs-guix great again :)

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

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