bug#67290: (current-profile) only works when invoked as a process named "guix"

bug#67290: (current-profile) only works when invoked as a process named "guix"

[Ian Eure]

When you invoke `guix repl', the current-profile and current-channels procedures reflect my current profile and channel configuration:

    l0p!ieure~$ guix repl
    GNU Guile 3.0.9
    Copyright (C) 1995-2023 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)> ,m (guix describe)
    scheme@(guix describe)> (current-profile)
    $1 = "/home/ieure/.config/guix/current"
    scheme@(guix describe)> (length (current-channels))
    $2 = 3
    scheme@(guix describe)> 

If you run `guile', they do not:

    l0p!ieure~$ guile
    GNU Guile 3.0.9
    Copyright (C) 1995-2023 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 (guix describe)
    scheme@(guix describe)> (current-profile)
    $1 = #f
    scheme@(guix describe)> (length (current-channels))
    $2 = 1
    scheme@(guix describe)> 

The issue seems to be that current-profile checks the name of the program which was invoked, and always returns #f unless the name ends with "bin/guix".  Since "guile" doesn’t, they don’t work as expected.  See: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/describe.scm#n64

I discovered this when I was using emacs-guix to debug one of my package definitions, which inherits from a package in a non-default channel.  While I can load the .scm file into Geiser no matter what channels are configured, it can’t use the module containing the package definition it inherits from.  This also appears to be the root cause behind this three-year-old bug report for emacs-guix: https://gitlab.com/emacs-guix/emacs-guix/-/issues/17

I’m not sure what the rationale is for this behavior, so I don’t have a suggestion for a fix, but it’s definitely a bug.

Thanks,

  — Ian

bug#67290: (current-profile) only works when invoked as a process named "guix"

[Simon Tournier]

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

Hi,

On Sun, 19 Nov 2023 at 13:24, Ian Eure <ian@retrospec.tv> wrote:

> The issue seems to be that current-profile checks the name of the
> program which was invoked, and always returns #f unless the name ends
> with "bin/guix".  Since "guile" doesn’t, they don’t work as expected.
> See:
> https://git.savannah.gnu.org/cgit/guix.git/tree/guix/describe.scm#n64

About current-profile, maybe this patch:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: p.patch --]
[-- Type: text/x-diff, Size: 1616 bytes --]

diff --git a/guix/describe.scm b/guix/describe.scm
index 65cd79094b..4147d5db1f 100644
--- a/guix/describe.scm
+++ b/guix/describe.scm
@@ -61,14 +61,18 @@ (define current-profile
 or #f if this is not applicable."
     (match initial-program-arguments
       ((program . _)
-       (and (string-suffix? "/bin/guix" program)
-            ;; Note: We want to do _lexical dot-dot resolution_.  Using ".."
-            ;; for real would instead take us into the /gnu/store directory
-            ;; that ~/.config/guix/current/bin points to, whereas we want to
-            ;; obtain ~/.config/guix/current.
-            (let ((candidate (dirname (dirname program))))
-              (and (file-exists? (string-append candidate "/manifest"))
-                   candidate)))))))
+       (or (and (string-suffix? "/bin/guix" program)
+                ;; Note: We want to do _lexical dot-dot resolution_.  Using ".."
+                ;; for real would instead take us into the /gnu/store directory
+                ;; that ~/.config/guix/current/bin points to, whereas we want to
+                ;; obtain ~/.config/guix/current.
+                (let ((candidate (dirname (dirname program))))
+                  (and (file-exists? (string-append candidate "/manifest"))
+                       candidate)))
+           (let ((current (string-append
+                           (config-directory #:ensure? #f) "/current/manifest")))
+             (and (file-exists? current)
+                  current)))))))
 
 (define (current-profile-date)
   "Return the creation date of the current profile (produced by 'guix pull'),

[-- Attachment #3: Type: text/plain, Size: 400 bytes --]


?

Well, I do not know exactly if fixing your issue does not introduce
regression.

About emacs-guix, instead of launching Guile, why not start “guix
repl” instead?  The command “guix repl” had been improved – and maybe
even introduced after the release of emacs-guix.  Somehow, I am not very
happy with the current integration between Geiser and Guix. :-)

Cheers,
simon

bug#67290: (current-profile) only works when invoked as a process named "guix"

[Ian Eure]

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Hi,
>
> On Sun, 19 Nov 2023 at 13:24, Ian Eure <ian@retrospec.tv> wrote:
>
>> The issue seems to be that current-profile checks the name of 
>> the
>> program which was invoked, and always returns #f unless the 
>> name ends
>> with "bin/guix".  Since "guile" doesn’t, they don’t work as 
>> expected.
>> See:
>> https://git.savannah.gnu.org/cgit/guix.git/tree/guix/describe.scm#n64
>
> About current-profile, maybe this patch:
>
> [2. p.patch --- text/x-diff; p.patch]
> diff --git a/guix/describe.scm b/guix/describe.scm
> index 65cd79094b..4147d5db1f 100644
> --- a/guix/describe.scm
> +++ b/guix/describe.scm
> @@ -61,14 +61,18 @@ (define current-profile
>  or #f if this is not applicable."
>      (match initial-program-arguments
>        ((program . _)
> -       (and (string-suffix? "/bin/guix" program)
> -            ;; Note: We want to do _lexical dot-dot 
> resolution_.  Using ".."
> -            ;; for real would instead take us into the 
> /gnu/store directory
> -            ;; that ~/.config/guix/current/bin points to, 
> whereas we want to
> -            ;; obtain ~/.config/guix/current.
> -            (let ((candidate (dirname (dirname program))))
> -              (and (file-exists? (string-append candidate 
> "/manifest"))
> -                   candidate)))))))
> +       (or (and (string-suffix? "/bin/guix" program)
> +                ;; Note: We want to do _lexical dot-dot 
> resolution_.  Using ".."
> +                ;; for real would instead take us into the 
> /gnu/store directory
> +                ;; that ~/.config/guix/current/bin points to, 
> whereas we want to
> +                ;; obtain ~/.config/guix/current.
> +                (let ((candidate (dirname (dirname program))))
> +                  (and (file-exists? (string-append candidate 
> "/manifest"))
> +                       candidate)))
> +           (let ((current (string-append
> +                           (config-directory #:ensure? #f) 
> "/current/manifest")))
> +             (and (file-exists? current)
> +                  current)))))))
>  
>  (define (current-profile-date)
>    "Return the creation date of the current profile (produced by 
>    'guix pull'),
>
>
> ?
>
> Well, I do not know exactly if fixing your issue does not 
> introduce
> regression.
>

The patch looks good to me, but this is all stuff I’m not very 
familiar with.


> About emacs-guix, instead of launching Guile, why not start 
> “guix
> repl” instead?  The command “guix repl” had been improved – and 
> maybe
> even introduced after the release of emacs-guix.  Somehow, I am 
> not very
> happy with the current integration between Geiser and Guix. :-)
>

I’m not sure why it works the way it does, or whether it could be 
changed to invoke `guix repl'.

I don’t think it’s expected for library code behavior to change 
depending on the runtime context, so I believe fixing Guix is the 
right solution.  Perhaps the concerns around resolving relative 
paths belongs somewhere more proximate to where that’s an issue? 
I definitely don’t understand everything happening in this code, 
but it strikes me as a concern relevant to some operations 
executed from the CLI.  If that’s the case, putting it in the CLI 
tooling where special handling is needed would make sense to me.

  — Ian