unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: "Tobias Geerinckx-Rice" <me@tobias.gr>,
	guix-devel@gnu.org, jgart <jgart@dismail.de>,
	"Ludovic Courtès" <ludo@gnu.org>
Cc: Guix Devel <guix-devel@gnu.org>
Subject: Re: repl macro (metacommand?) for guix CLI (sub)commands
Date: Tue, 05 Jul 2022 00:47:07 +0200	[thread overview]
Message-ID: <86tu7wxzpw.fsf@gmail.com> (raw)
In-Reply-To: <AE8760FD-4D77-4E24-9536-C908DD3A86AE@tobias.gr>

Hi,

>>This is because each of those "CLI calls" end up running `(exit 0)`
>>at the end in some form or another.

Quote:

        What do guixers think of having a repl macro that allows you to
        run commands like if you were using the CLI?

        <https://yhetil.org/guix/20220703131112.GB5967@gac>

therefore using (guix-package "-s" "non-existent") «allows you to run
commands like if you were using the CLI». ;-)


> Should they?  Is this an accepted pattern in the functional style to
> which Guix tries to adhere?
>
> (I don't know!  It just caught me by surprise.)

For instance it reads,

--8<---------------cut here---------------start------------->8---
(define %options
  ;; Specification of the command-line options.
  (cons* (option '(#\h "help") #f #f
                 (lambda args
                   (show-help)
                   (exit 0)))
--8<---------------cut here---------------end--------------->8---

or elsewhere for another instance,

--8<---------------cut here---------------start------------->8---
  (define (handle-argument arg result arg-handler)
    ;; Process non-option argument ARG by calling back ARG-HANDLER.
    (if arg-handler
        (arg-handler arg result)
        (leave (G_ "~A: extraneous argument~%") arg)))
--8<---------------cut here---------------end--------------->8---

where ’leave’ reads,

--8<---------------cut here---------------start------------->8---
(define-syntax-rule (leave args ...)
  "Emit an error message and exit."
  (begin
    (report-error args ...)
    (exit 1)))
--8<---------------cut here---------------end--------------->8---

It appears to me expected that the imperative CLI called from shell
returns meaningful code that the shell caller can use.


I do not know what is expected for working at the REPL.  The direct use
’define-command’ is a quick workaround.  Other said, the run of

    scheme@(guix-user)> (guix-package "-s" "hello")

instead of the CLI “guix package -s hello” is just to expose an entry
point for the Scheme API.  Because the procedure ’guix-package’ is to
somehow make a compatible layer between the functional style with the
imperative shell world – hence all the ’leave’ or ’warning’ glue code.


Except some corner cases, the general idea, from my understanding, is to
have all the impure/imperative code under guix/scripts/.  Although it is
sadly more than often not the case; give a look at (gnu packages) for
instance.  Anyway.


Well, the functional style at the REPL would to directly use for example
’find-packages-by-description’ or the like; although this procedure is
not exposed by the API.


All that said, maybe it could be nice to extend the current
meta-commands of the REPL.  What would be the need between the current
CLI and the current Scheme API?

Maybe all the ’leave’ and ’exit’ could be wrapped using an hypothetical
’maybe-exit’ catching if it is called from REPL or not.

Is it possible to detect if an interactive call?  I was thinking to add
a global parameter in ’(guix scripts repl) and then this new
’maybe-exit’ could check it; but I guess Guile provides a better
mechanism for checking interactiveness.


Cheers,
simon


  reply	other threads:[~2022-07-04 22:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-03 18:11 repl macro (metacommand?) for guix CLI (sub)commands jgart
2022-07-04  8:29 ` zimoun
2022-07-04 13:22 ` Ludovic Courtès
2022-07-04 18:21   ` jgart
2022-07-04 20:28     ` Tobias Geerinckx-Rice
2022-07-04 22:47       ` zimoun [this message]
2022-07-05 22:27         ` jgart
2022-07-06  6:44           ` zimoun
2022-07-06 12:13             ` bokr
2022-07-06 12:58               ` zimoun
2022-07-16 19:08                 ` Bengt Richter
2022-07-07  7:31     ` Ludovic Courtès
2022-07-07  7:58       ` bokr

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=86tu7wxzpw.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=jgart@dismail.de \
    --cc=ludo@gnu.org \
    --cc=me@tobias.gr \
    /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).