unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: "Pierre Neidhardt" <mail@ambrevar.xyz>, "Ludovic Courtès" <ludo@gnu.org>
Cc: Development of GNU Guix and the GNU System distribution
	<guix-devel@gnu.org>, Ryan Prior <ryanprior@hey.com>
Subject: Re: Reviving Emacs-Guix
Date: Sat, 14 Nov 2020 22:11:36 +0100	[thread overview]
Message-ID: <86h7pry77b.fsf@gmail.com> (raw)
In-Reply-To: <87zh3jvjfj.fsf@ambrevar.xyz>

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


  parent reply	other threads:[~2020-11-14 21:15 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-10  5:07 Announcing emacs-guix-packaging Ryan Prior
2020-11-10 13:30 ` Pierre Neidhardt
2020-11-12 20:53 ` Ludovic Courtès
2020-11-13  1:28   ` Ryan Prior
2020-11-13  9:45     ` Pierre Neidhardt
2020-11-13 13:20       ` zimoun
2020-11-13 14:54         ` John Soo
2020-11-13 16:54       ` Reviving Emacs-Guix Ludovic Courtès
2020-11-13 17:13         ` John Soo
2020-11-13 18:42         ` zimoun
2020-11-16  8:56           ` Ludovic Courtès
2020-11-14  9:42         ` Pierre Neidhardt
2020-11-14 12:57           ` zimoun
2020-11-14 15:59             ` Pierre Neidhardt
2020-11-14 16:56               ` zimoun
2020-11-14 17:30                 ` Pierre Neidhardt
2020-11-14 18:40                   ` zimoun
2020-11-14 19:15                     ` Pierre Neidhardt
2020-11-14 19:52                       ` Ricardo Wurmus
2020-11-14 21:29                         ` zimoun
2020-11-15  7:37                           ` Pierre Neidhardt
2020-11-15 13:15                             ` zimoun
2020-11-15 14:11                               ` Pierre Neidhardt
2020-11-15 15:23                                 ` zimoun
2020-11-15 15:45                                   ` Pierre Neidhardt
2020-11-15 16:05                                     ` zimoun
2020-11-14 21:11                       ` zimoun [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86h7pry77b.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    --cc=mail@ambrevar.xyz \
    --cc=ryanprior@hey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).