* Announcing emacs-guix-packaging @ 2020-11-10 5:07 Ryan Prior 2020-11-10 13:30 ` Pierre Neidhardt 2020-11-12 20:53 ` Ludovic Courtès 0 siblings, 2 replies; 37+ messages in thread From: Ryan Prior @ 2020-11-10 5:07 UTC (permalink / raw) To: Simon Josefsson via Development of GNU Guix and the GNU System distribution. [-- 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 --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Announcing emacs-guix-packaging 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 1 sibling, 0 replies; 37+ messages in thread From: Pierre Neidhardt @ 2020-11-10 13:30 UTC (permalink / raw) To: Ryan Prior, Simon Josefsson via Development of GNU Guix and the GNU System distribution. [-- 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 --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Announcing emacs-guix-packaging 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 1 sibling, 1 reply; 37+ messages in thread From: Ludovic Courtès @ 2020-11-12 20:53 UTC (permalink / raw) To: Ryan Prior Cc: Simon Josefsson via Development of GNU Guix and the GNU System distribution. 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’. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Announcing emacs-guix-packaging 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 12:31 ` Announcing emacs-guix-packaging zimoun 0 siblings, 2 replies; 37+ messages in thread From: Ryan Prior @ 2020-11-13 1:28 UTC (permalink / raw) To: Ludovic Courtès Cc: Development of GNU Guix and the GNU System distribution [-- 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 --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Announcing emacs-guix-packaging 2020-11-13 1:28 ` Ryan Prior @ 2020-11-13 9:45 ` Pierre Neidhardt 2020-11-13 13:20 ` zimoun 2020-11-13 16:54 ` Reviving Emacs-Guix Ludovic Courtès 2020-11-13 12:31 ` Announcing emacs-guix-packaging zimoun 1 sibling, 2 replies; 37+ messages in thread From: Pierre Neidhardt @ 2020-11-13 9:45 UTC (permalink / raw) To: Ryan Prior, Ludovic Courtès Cc: Development of GNU Guix and the GNU System distribution [-- 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 --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Announcing emacs-guix-packaging 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 1 sibling, 1 reply; 37+ messages in thread From: zimoun @ 2020-11-13 13:20 UTC (permalink / raw) To: Pierre Neidhardt, Ryan Prior, Ludovic Courtès Cc: Development of GNU Guix and the GNU System distribution 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Announcing emacs-guix-packaging 2020-11-13 13:20 ` zimoun @ 2020-11-13 14:54 ` John Soo 0 siblings, 0 replies; 37+ messages in thread From: John Soo @ 2020-11-13 14:54 UTC (permalink / raw) To: zimoun; +Cc: Development of GNU Guix and the GNU System distribution, Ryan Prior 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Reviving Emacs-Guix 2020-11-13 9:45 ` Pierre Neidhardt 2020-11-13 13:20 ` zimoun @ 2020-11-13 16:54 ` Ludovic Courtès 2020-11-13 17:13 ` John Soo ` (2 more replies) 1 sibling, 3 replies; 37+ messages in thread From: Ludovic Courtès @ 2020-11-13 16:54 UTC (permalink / raw) To: Pierre Neidhardt Cc: Development of GNU Guix and the GNU System distribution, Ryan Prior 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 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-14 9:42 ` Pierre Neidhardt 2 siblings, 0 replies; 37+ messages in thread From: John Soo @ 2020-11-13 17:13 UTC (permalink / raw) To: Ludovic Courtès Cc: Development of GNU Guix and the GNU System distribution, Ryan Prior 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 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 2 siblings, 1 reply; 37+ messages in thread From: zimoun @ 2020-11-13 18:42 UTC (permalink / raw) To: Ludovic Courtès, Pierre Neidhardt Cc: Development of GNU Guix and the GNU System distribution, Ryan Prior 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 2020-11-13 18:42 ` zimoun @ 2020-11-16 8:56 ` Ludovic Courtès 0 siblings, 0 replies; 37+ messages in thread From: Ludovic Courtès @ 2020-11-16 8:56 UTC (permalink / raw) To: zimoun; +Cc: Development of GNU Guix and the GNU System distribution, Ryan Prior 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’. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 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-14 9:42 ` Pierre Neidhardt 2020-11-14 12:57 ` zimoun 2020-11-14 19:49 ` Ricardo Wurmus 2 siblings, 2 replies; 37+ messages in thread From: Pierre Neidhardt @ 2020-11-14 9:42 UTC (permalink / raw) To: Ludovic Courtès Cc: Development of GNU Guix and the GNU System distribution, Ryan Prior [-- 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 --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 2020-11-14 9:42 ` Pierre Neidhardt @ 2020-11-14 12:57 ` zimoun 2020-11-14 15:59 ` Pierre Neidhardt 2020-11-14 19:49 ` Ricardo Wurmus 1 sibling, 1 reply; 37+ messages in thread From: zimoun @ 2020-11-14 12:57 UTC (permalink / raw) To: Pierre Neidhardt, Ludovic Courtès Cc: Development of GNU Guix and the GNU System distribution, Ryan Prior 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 2020-11-14 12:57 ` zimoun @ 2020-11-14 15:59 ` Pierre Neidhardt 2020-11-14 16:56 ` zimoun 0 siblings, 1 reply; 37+ messages in thread From: Pierre Neidhardt @ 2020-11-14 15:59 UTC (permalink / raw) To: zimoun, Ludovic Courtès Cc: Development of GNU Guix and the GNU System distribution, Ryan Prior [-- 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 --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 2020-11-14 15:59 ` Pierre Neidhardt @ 2020-11-14 16:56 ` zimoun 2020-11-14 17:30 ` Pierre Neidhardt 0 siblings, 1 reply; 37+ messages in thread From: zimoun @ 2020-11-14 16:56 UTC (permalink / raw) To: Pierre Neidhardt, Ludovic Courtès Cc: Development of GNU Guix and the GNU System distribution, Ryan Prior 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 2020-11-14 16:56 ` zimoun @ 2020-11-14 17:30 ` Pierre Neidhardt 2020-11-14 18:40 ` zimoun 0 siblings, 1 reply; 37+ messages in thread From: Pierre Neidhardt @ 2020-11-14 17:30 UTC (permalink / raw) To: zimoun, Ludovic Courtès Cc: Development of GNU Guix and the GNU System distribution, Ryan Prior [-- 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 --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 2020-11-14 17:30 ` Pierre Neidhardt @ 2020-11-14 18:40 ` zimoun 2020-11-14 19:15 ` Pierre Neidhardt 0 siblings, 1 reply; 37+ messages in thread From: zimoun @ 2020-11-14 18:40 UTC (permalink / raw) To: Pierre Neidhardt, Ludovic Courtès Cc: Development of GNU Guix and the GNU System distribution, Ryan Prior 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 2020-11-14 18:40 ` zimoun @ 2020-11-14 19:15 ` Pierre Neidhardt 2020-11-14 19:52 ` Ricardo Wurmus 2020-11-14 21:11 ` zimoun 0 siblings, 2 replies; 37+ messages in thread From: Pierre Neidhardt @ 2020-11-14 19:15 UTC (permalink / raw) To: zimoun, Ludovic Courtès Cc: Development of GNU Guix and the GNU System distribution, Ryan Prior [-- 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 --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 2020-11-14 19:15 ` Pierre Neidhardt @ 2020-11-14 19:52 ` Ricardo Wurmus 2020-11-14 21:29 ` zimoun 2020-11-14 21:11 ` zimoun 1 sibling, 1 reply; 37+ messages in thread From: Ricardo Wurmus @ 2020-11-14 19:52 UTC (permalink / raw) To: Pierre Neidhardt; +Cc: guix-devel, Ryan Prior 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 2020-11-14 19:52 ` Ricardo Wurmus @ 2020-11-14 21:29 ` zimoun 2020-11-15 7:37 ` Pierre Neidhardt 0 siblings, 1 reply; 37+ messages in thread From: zimoun @ 2020-11-14 21:29 UTC (permalink / raw) To: Ricardo Wurmus, Pierre Neidhardt; +Cc: guix-devel, Ryan Prior 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 2020-11-14 21:29 ` zimoun @ 2020-11-15 7:37 ` Pierre Neidhardt 2020-11-15 13:15 ` zimoun 0 siblings, 1 reply; 37+ messages in thread From: Pierre Neidhardt @ 2020-11-15 7:37 UTC (permalink / raw) To: zimoun, Ricardo Wurmus; +Cc: guix-devel, Ryan Prior [-- 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 --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 2020-11-15 7:37 ` Pierre Neidhardt @ 2020-11-15 13:15 ` zimoun 2020-11-15 14:11 ` Pierre Neidhardt 0 siblings, 1 reply; 37+ messages in thread From: zimoun @ 2020-11-15 13:15 UTC (permalink / raw) To: Pierre Neidhardt, Ricardo Wurmus; +Cc: guix-devel, Ryan Prior 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? ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 2020-11-15 13:15 ` zimoun @ 2020-11-15 14:11 ` Pierre Neidhardt 2020-11-15 15:23 ` zimoun 0 siblings, 1 reply; 37+ messages in thread From: Pierre Neidhardt @ 2020-11-15 14:11 UTC (permalink / raw) To: zimoun, Ricardo Wurmus; +Cc: guix-devel, Ryan Prior [-- 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 --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 2020-11-15 14:11 ` Pierre Neidhardt @ 2020-11-15 15:23 ` zimoun 2020-11-15 15:45 ` Pierre Neidhardt 0 siblings, 1 reply; 37+ messages in thread From: zimoun @ 2020-11-15 15:23 UTC (permalink / raw) To: Pierre Neidhardt, Ricardo Wurmus; +Cc: guix-devel, Ryan Prior 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 2020-11-15 15:23 ` zimoun @ 2020-11-15 15:45 ` Pierre Neidhardt 2020-11-15 16:05 ` zimoun 0 siblings, 1 reply; 37+ messages in thread From: Pierre Neidhardt @ 2020-11-15 15:45 UTC (permalink / raw) To: zimoun, Ricardo Wurmus; +Cc: guix-devel, Ryan Prior [-- 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 --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 2020-11-15 15:45 ` Pierre Neidhardt @ 2020-11-15 16:05 ` zimoun 0 siblings, 0 replies; 37+ messages in thread From: zimoun @ 2020-11-15 16:05 UTC (permalink / raw) To: Pierre Neidhardt, Ricardo Wurmus; +Cc: guix-devel, Ryan Prior 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 2020-11-14 19:15 ` Pierre Neidhardt 2020-11-14 19:52 ` Ricardo Wurmus @ 2020-11-14 21:11 ` zimoun 2020-11-15 7:53 ` Pierre Neidhardt 1 sibling, 1 reply; 37+ messages in thread From: zimoun @ 2020-11-14 21:11 UTC (permalink / raw) To: Pierre Neidhardt, Ludovic Courtès Cc: Development of GNU Guix and the GNU System distribution, Ryan Prior 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 2020-11-14 21:11 ` zimoun @ 2020-11-15 7:53 ` Pierre Neidhardt 0 siblings, 0 replies; 37+ messages in thread From: Pierre Neidhardt @ 2020-11-15 7:53 UTC (permalink / raw) To: zimoun, Ludovic Courtès Cc: Development of GNU Guix and the GNU System distribution, Ryan Prior [-- 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 --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 2020-11-14 9:42 ` Pierre Neidhardt 2020-11-14 12:57 ` zimoun @ 2020-11-14 19:49 ` Ricardo Wurmus 2020-11-15 7:36 ` Pierre Neidhardt 2020-11-16 9:02 ` Ludovic Courtès 1 sibling, 2 replies; 37+ messages in thread From: Ricardo Wurmus @ 2020-11-14 19:49 UTC (permalink / raw) To: Pierre Neidhardt; +Cc: guix-devel, Ryan Prior 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 2020-11-14 19:49 ` Ricardo Wurmus @ 2020-11-15 7:36 ` Pierre Neidhardt 2020-11-16 9:02 ` Ludovic Courtès 1 sibling, 0 replies; 37+ messages in thread From: Pierre Neidhardt @ 2020-11-15 7:36 UTC (permalink / raw) To: Ricardo Wurmus; +Cc: guix-devel, Ryan Prior [-- 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 --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 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 1 sibling, 1 reply; 37+ messages in thread From: Ludovic Courtès @ 2020-11-16 9:02 UTC (permalink / raw) To: Ricardo Wurmus; +Cc: guix-devel, Ryan Prior 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’. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 2020-11-16 9:02 ` Ludovic Courtès @ 2020-11-16 9:18 ` Pierre Neidhardt 2020-11-16 12:01 ` zimoun 0 siblings, 1 reply; 37+ messages in thread From: Pierre Neidhardt @ 2020-11-16 9:18 UTC (permalink / raw) To: Ludovic Courtès, Ricardo Wurmus; +Cc: guix-devel, Ryan Prior [-- 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 --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 2020-11-16 9:18 ` Pierre Neidhardt @ 2020-11-16 12:01 ` zimoun 2020-11-16 12:20 ` Pierre Neidhardt 0 siblings, 1 reply; 37+ messages in thread From: zimoun @ 2020-11-16 12:01 UTC (permalink / raw) To: Pierre Neidhardt, Ludovic Courtès, Ricardo Wurmus Cc: guix-devel, Ryan Prior 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 2020-11-16 12:01 ` zimoun @ 2020-11-16 12:20 ` Pierre Neidhardt 2020-11-16 12:47 ` zimoun 0 siblings, 1 reply; 37+ messages in thread From: Pierre Neidhardt @ 2020-11-16 12:20 UTC (permalink / raw) To: zimoun, Ludovic Courtès, Ricardo Wurmus; +Cc: guix-devel, Ryan Prior [-- 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 --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 2020-11-16 12:20 ` Pierre Neidhardt @ 2020-11-16 12:47 ` zimoun 2020-11-17 7:53 ` Pierre Neidhardt 0 siblings, 1 reply; 37+ messages in thread From: zimoun @ 2020-11-16 12:47 UTC (permalink / raw) To: Pierre Neidhardt, Ludovic Courtès, Ricardo Wurmus Cc: guix-devel, Ryan Prior 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Reviving Emacs-Guix 2020-11-16 12:47 ` zimoun @ 2020-11-17 7:53 ` Pierre Neidhardt 0 siblings, 0 replies; 37+ messages in thread From: Pierre Neidhardt @ 2020-11-17 7:53 UTC (permalink / raw) To: zimoun, Ludovic Courtès, Ricardo Wurmus; +Cc: guix-devel, Ryan Prior [-- 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 --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Announcing emacs-guix-packaging 2020-11-13 1:28 ` Ryan Prior 2020-11-13 9:45 ` Pierre Neidhardt @ 2020-11-13 12:31 ` zimoun 1 sibling, 0 replies; 37+ messages in thread From: zimoun @ 2020-11-13 12:31 UTC (permalink / raw) To: Ryan Prior, Ludovic Courtès Cc: Development of GNU Guix and the GNU System distribution 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2020-11-17 7:53 UTC | newest] Thread overview: 37+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 ` Announcing emacs-guix-packaging zimoun
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.