repl macro (metacommand?) for guix CLI (sub)commands

repl macro (metacommand?) for guix CLI (sub)commands

[jgart]

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

Inspiration:

https://github.com/janet-lang/jpm/commit/6d494db43605b9fc7411875f25ae110cb8f77e0b

all best,

jgart

Re: repl macro (metacommand?) for guix CLI (sub)commands

[zimoun]

Hi,

On Sun, 03 Jul 2022 at 13:11, jgart <jgart@dismail.de> wrote:
> What do guixers think of having a repl macro that allows
> you to run commands like if you were using the CLI?

I am not sure to understand the question.  Well, it is already possible,
no?

--8<---------------cut here---------------start------------->8---
$ guix repl
GNU Guile 3.0.8
Copyright (C) 1995-2021 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@(guix-user)> ,use(guix scripts show)
scheme@(guix-user)> (guix-show "hello")
name: hello
version: 2.12.1
outputs: out
systems: x86_64-linux i686-linux
dependencies: 
location: gnu/packages/base.scm:86:2
homepage: https://www.gnu.org/software/hello/
license: GPL 3+
synopsis: Hello, GNU world: An example GNU package  
description: GNU Hello prints the message "Hello, world!" and then exits.  It serves as an example of standard GNU
+ coding practices.  As such, it supports command-line arguments, multiple languages, and so on.

$1 = #t
scheme@(guix-user)> ,use(guix scripts package)
scheme@(guix-user)> (guix-package "-s" "hello")
[...]
--8<---------------cut here---------------end--------------->8---

Obviously, using CLI at the REPL is always not handy,

--8<---------------cut here---------------start------------->8---
scheme@(guix-user)> (guix-show "helloo")
guix repl: error: helloo: package not found
$ 
--8<---------------cut here---------------end--------------->8---


Cheers,
simon

Re: repl macro (metacommand?) for guix CLI (sub)commands

[Ludovic Courtès]

Hi,

jgart <jgart@dismail.de> skribis:

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

In addition to what zimoun wrote, see this discussion about providing
REPL metacommands to lower or build things:

  https://issues.guix.gnu.org/56114

Ludo’.

Re: repl macro (metacommand?) for guix CLI (sub)commands

[jgart]

On Mon, 04 Jul 2022 15:22:09 +0200 Ludovic Courtès <ludo@gnu.org> wrote:
> In addition to what zimoun wrote, see this discussion about providing
> REPL metacommands to lower or build things:

Simoun, thanks for the repl session demo. I hadn't tried running the
guix scripts modules at the repl yet. Ludo, thanks for the metacommand
discussion link. It's much appreciated!

In exploring at the repl a bit now I realized that running

`(guix-package "--help")` or `(guix-package "--version")` causes the
repl to exit.

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

Would it be desireable to write some extra code to have the `guix-*`
"CLI functions" not call `(exit 0)` if in a repl and call it if using
from the command line? I imagine that this is only desireable if using
the command line? That way I won't be thrown out of the repl session by
accident and the experience would be more like the CLI experience.

I'm thinking something like a `maybe-exit` and
`show-version-and-maybe-exit` function instead of `(exit 0)` and
`show-version-and-exit` as currently used, respectively.

I'm not sure at the moment on how to detect if I am in a repl when
calling those functions or if I am calling them from the command line.

What do you think?

--
jgart

Re: repl macro (metacommand?) for guix CLI (sub)commands

[Tobias Geerinckx-Rice]

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

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

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

Re: repl macro (metacommand?) for guix CLI (sub)commands

[zimoun]

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

Re: repl macro (metacommand?) for guix CLI (sub)commands

[jgart]

On Tue, 05 Jul 2022 00:47:07 +0200 zimoun <zimon.toutoune@gmail.com> wrote:
> 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?

Hi,

That's a good question! Maybe we should make a feature table and analyze
what we currently have exposed to decide what we might want in the near
future that we don't currently have.

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

I'll have to read more code. I was just imagining something like that could work.

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

Do you know if guile provides a way of checking that? Should we ask on the guile mailing
list or should we read more code first to see what's currently provided?

all best,

jgart

Re: repl macro (metacommand?) for guix CLI (sub)commands

[zimoun]

Hi,

On mar., 05 juil. 2022 at 17:27, jgart <jgart@dismail.de> wrote:

> That's a good question! Maybe we should make a feature table and analyze
> what we currently have exposed to decide what we might want in the near
> future that we don't currently have.

What is already exposed:

--8<---------------cut here---------------start------------->8---
$ guix repl
GNU Guile 3.0.8
Copyright (C) 1995-2021 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@(guix-user)> ,help guix
Guix Commands [abbrev]:

 ,run-in-store EXP                 - Run EXP through the store monad.
 ,enter-store-monad                - Enter a REPL for values in the store monad.

scheme@(guix-user)>
--8<---------------cut here---------------end--------------->8---

And patch#56114 [1] introduce in addition:

 ,verbosity LEVEL                  - Change build verbosity to LEVEL.
 ,lower OBJECT                     - Lower OBJECT into a derivation and return it.
 ,build OBJECT                     - Lower OBJECT and build it, returning its output file name(s).


1: <https://issues.guix.gnu.org/56114>


>> 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.
>
> Do you know if guile provides a way of checking that? Should we ask on
> the guile mailing list or should we read more code first to see what's
> currently provided?

I do not know about a Guile feature allowing to check the
interactiveness.  It seems worth to ask on Guile mailing list because,
if such feature exists then, I have missed from the Guile manual.


Cheers,
simon

Re: repl macro (metacommand?) for guix CLI (sub)commands

[bokr]

Hi,

On +2022-07-06 08:44:32 +0200, zimoun wrote:
> Hi,
> 
> On mar., 05 juil. 2022 at 17:27, jgart <jgart@dismail.de> wrote:
> 
> > That's a good question! Maybe we should make a feature table and analyze
> > what we currently have exposed to decide what we might want in the near
> > future that we don't currently have.
> 
> What is already exposed:
> 
> --8<---------------cut here---------------start------------->8---
> $ guix repl
> GNU Guile 3.0.8
> Copyright (C) 1995-2021 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@(guix-user)> ,help guix
> Guix Commands [abbrev]:
> 
>  ,run-in-store EXP                 - Run EXP through the store monad.
>  ,enter-store-monad                - Enter a REPL for values in the store monad.
> 
> scheme@(guix-user)>
> --8<---------------cut here---------------end--------------->8---
> 
> And patch#56114 [1] introduce in addition:
> 
>  ,verbosity LEVEL                  - Change build verbosity to LEVEL.
>  ,lower OBJECT                     - Lower OBJECT into a derivation and return it.
>  ,build OBJECT                     - Lower OBJECT and build it, returning its output file name(s).
> 
> 
> 1: <https://issues.guix.gnu.org/56114>
> 
> 
> >> 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.
> >
> > Do you know if guile provides a way of checking that? Should we ask on
> > the guile mailing list or should we read more code first to see what's
> > currently provided?
> 
> I do not know about a Guile feature allowing to check the
> interactiveness.  It seems worth to ask on Guile mailing list because,
> if such feature exists then, I have missed from the Guile manual.
> 
> 
> Cheers,
> simon
> 

I think (IANA bash expert) PS1 should be a pretty good indicator,
unless something funny is going on :)

(Note the difference between executing and sourcing):

(IDK if other shells use PS1 so it would work in such environments)
I looked in man ps to see if possibly ps -o <something> could make
an easy check (seems like there ought to be, but I am out of time
after almost an hour of experimenting :/ )

--8<---------------cut here---------------start------------->8---
[13:23 ~/bs]$ guile --no-auto-compile -c '(display (getenv "PS1"))(newline)'
[\A \w]\$ 
[13:24 ~/bs]$ ./guile-non-int-call 
PS1_val='#f'
#f
[13:24 ~/bs]$ source ./guile-non-int-call 
PS1_val='[\A \w]\$ '
[\A \w]\$ 
[13:24 ~/bs]$ cat -nA ./guile-non-int-call
     1  #!/usr/bin/bash$
     2  PS1_val="$(guile --no-auto-compile -c '(display (getenv "PS1"))(newline)')"$
     3  echo "PS1_val='$PS1_val'"$
     4  guile --no-auto-compile -c '(display (getenv "PS1"))(newline)'$
[13:25 ~/bs]$ 
--8<---------------cut here---------------end--------------->8---

HTH
--
Regards
Bengt Richter

Re: repl macro (metacommand?) for guix CLI (sub)commands

[zimoun]

Hi,

On mer., 06 juil. 2022 at 14:13, bokr@bokr.com wrote:

> [13:23 ~/bs]$ guile --no-auto-compile -c '(display (getenv "PS1"))(newline)'
> [\A \w]\$ 

On my machine, all is as usual and I run Bash:

--8<---------------cut here---------------start------------->8---
$ echo $PS1
\n\w/\n\u@\h$
$ guile --no-auto-compile -c '(display (getenv "PS1"))(newline)'
#f
--8<---------------cut here---------------end--------------->8---

Maybe I miss something.   Thanks for giving a try.


Cheers,
simon

Re: repl macro (metacommand?) for guix CLI (sub)commands

[Ludovic Courtès]

Hi!

jgart <jgart@dismail.de> skribis:

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

Note that Guile’s ‘exit’ throws a ‘quit’ exception, which can be caught.

Ludo’.

Re: repl macro (metacommand?) for guix CLI (sub)commands

[bokr]

Hi Ludo',

On +2022-07-07 09:31:34 +0200, Ludovic Courtès wrote:
> Hi!
> 
> jgart <jgart@dismail.de> skribis:
> 
> > This is because each of those "CLI calls" end up running `(exit 0)`
> > at the end in some form or another.
> 
> Note that Guile’s ‘exit’ throws a ‘quit’ exception, which can be caught.

Any possible gotchas in throwing 'quit' re flush-close-sync?

> 
> Ludo’.
>
--
Regards,
Bengt Richter

Re: repl macro (metacommand?) for guix CLI (sub)commands

[Bengt Richter]

Hi Simon,

On +2022-07-06 14:58:29 +0200, zimoun wrote:
> Hi,
> 
> On mer., 06 juil. 2022 at 14:13, bokr@bokr.com wrote:
> 
> > [13:23 ~/bs]$ guile --no-auto-compile -c '(display (getenv "PS1"))(newline)'
> > [\A \w]\$ 
> 
> On my machine, all is as usual and I run Bash:
> 
> --8<---------------cut here---------------start------------->8---
> $ echo $PS1
> \n\w/\n\u@\h$
> $ guile --no-auto-compile -c '(display (getenv "PS1"))(newline)'
> #f
> --8<---------------cut here---------------end--------------->8---
> 
> Maybe I miss something.   Thanks for giving a try.
> 
> 
> Cheers,
> simon
>

Hm, I see that on my system, I don't get #f from guile like you
--8<---------------cut here---------------start------------->8---
$ echo $PS1
[\A \w]\$
$ guile --no-auto-compile -c '(display (getenv "PS1"))(newline)'
[\A \w]\$ 
--8<---------------cut here---------------end--------------->8---

so I'm not sure what is the difference ;/

Since I was getting PS1 from a bash invocation of guile, I was had
a different impression from yours of reality ;-)

So I went looking for a context where invoking something would NOT see PS1 :)

I found that a nested call of a bash script did not see PS1 unless invoked by sourcing.
(Of course I can't source the guile I access with "guile" as a bash command, since it's
a binary.) But IIRC guile under guix is actually a wrapper script to set up the environment,
so maybe you could on your system -- I've no idea what would happen ;-)


I was thinking that the discussed problem must involve a guile script that
might not be able to sense that it was being invoked by an interactive
repl if it got executed in a nested way as a sub-command,
because the latter would not see a PS1 unless it was in its current environment.

So I was trying to point out that if from the repl you invoke the
nesting script by sourcing it instead of executing it, the sourcing
makes the execution happen in the current environment, and PS1 is seen
and apparently passed on to what the sourced script invokes.

I was lazy about separating stuff, sorry. Comments on the pieces follow:

--8<---------------cut here---------------start------------->8---

What you report above:
┌────────────────────────────────────────────────────────────────────┐
│ > $ echo $PS1                                                      │
│ > \n\w/\n\u@\h$                                                    │
│ > $ guile --no-auto-compile -c '(display (getenv "PS1"))(newline)' │
│ > #f                                                               │
│ >                                                                  │
└────────────────────────────────────────────────────────────────────┘

The guile I'm running:

{ which guile; guile -v; } 
--8<---------------cut here---------------start------------->8---
/usr/bin/guile
guile (GNU Guile) 2.2.4
Packaged by Debian (2.2.4-deb+1-2+deb10u1)
Copyright (C) 2018 Free Software Foundation, Inc.

License LGPLv3+: GNU LGPL 3 or later <http://gnu.org/licenses/lgpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
--8<---------------cut here---------------end--------------->8---

Me: Like you, but not getting #f -- my bug, presumably ? Should this return #f for sure?
┌──────────────────────────────────────────────────────────────────────────────┐
│ [13:23 ~/bs]$ guile --no-auto-compile -c '(display (getenv "PS1"))(newline)' │
│ [\A \w]\$                                                                    │
└──────────────────────────────────────────────────────────────────────────────┘
Invoking script[1]  as command, not sourcing -- no PS1 in the command's env nested
guile doesn't see it
┌─────────────────────────────────────┐
│ [13:24 ~/bs]$ ./guile-non-int-call  │
│ PS1_val='#f'                        │
│ #f                                  │
└─────────────────────────────────────┘
Sourcing makes the execution happen in the current env, so PS1 is visible
┌────────────────────────────────────────────┐
│ [13:24 ~/bs]$ source ./guile-non-int-call  │
│ PS1_val='[\A \w]\$ '                       │
│ [\A \w]\$                                  │
└────────────────────────────────────────────┘
[1] The script producing the above results as command vs sourced:
┌──────────────────────────────────────────────────────────────────────────────────────┐
│ [13:24 ~/bs]$ cat -nA ./guile-non-int-call                                           │
│      1  #!/usr/bin/bash$                                                             │
│      2  PS1_val="$(guile --no-auto-compile -c '(display (getenv "PS1"))(newline)')"$ │
│      3  echo "PS1_val='$PS1_val'"$                                                   │
│      4  guile --no-auto-compile -c '(display (getenv "PS1"))(newline)'$              │
│ [13:25 ~/bs]$                                                                        │
└──────────────────────────────────────────────────────────────────────────────────────┘
--8<---------------cut here---------------end--------------->8---

WDYT?
I need to go back to square 1 default .bash_login and .bashrc to debug this I guess :-(
(so .profile and my mods down the .profile sequence will be ignored). Gaah :-/
--
Regards,
Bengt Richter