Simon Tournier <zimon.touto...@gmail.com> writes:
Hi,
On Sun, 19 Nov 2023 at 13:24, Ian Eure <i...@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