* Recent change in 'guix package --search-paths' behavior?
@ 2017-05-10 8:45 Chris Marusich
2017-05-10 12:08 ` Ludovic Courtès
0 siblings, 1 reply; 5+ messages in thread
From: Chris Marusich @ 2017-05-10 8:45 UTC (permalink / raw)
To: guix-devel
[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]
Hi,
The manual says ((guix) Invoking guix package):
--8<---------------cut here---------------start------------->8---
This option can also be used to compute the _combined_ search paths
of several profiles. Consider this example:
$ guix package -p foo -i guile
$ guix package -p bar -i guile-json
$ guix package -p foo -p bar --search-paths
The last command above reports about the ‘GUILE_LOAD_PATH’
variable, even though, taken individually, neither ‘foo’ nor ‘bar’
would lead to that recommendation.
--8<---------------cut here---------------end--------------->8---
I've tried this just now, and the command says nothing about the
GUILE_LOAD_PATH:
--8<---------------cut here---------------start------------->8---
$ guix package -p foo -p bar --search-paths
export PATH="foo/bin"
--8<---------------cut here---------------end--------------->8---
Is the documentation wrong, or is this a regression?
--
Chris
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Recent change in 'guix package --search-paths' behavior?
2017-05-10 8:45 Recent change in 'guix package --search-paths' behavior? Chris Marusich
@ 2017-05-10 12:08 ` Ludovic Courtès
2017-05-11 7:07 ` Chris Marusich
0 siblings, 1 reply; 5+ messages in thread
From: Ludovic Courtès @ 2017-05-10 12:08 UTC (permalink / raw)
To: Chris Marusich; +Cc: guix-devel
Chris Marusich <cmmarusich@gmail.com> skribis:
> Hi,
>
> The manual says ((guix) Invoking guix package):
>
> This option can also be used to compute the _combined_ search paths
> of several profiles. Consider this example:
>
> $ guix package -p foo -i guile
> $ guix package -p bar -i guile-json
> $ guix package -p foo -p bar --search-paths
>
> The last command above reports about the ‘GUILE_LOAD_PATH’
> variable, even though, taken individually, neither ‘foo’ nor ‘bar’
> would lead to that recommendation.
[...]
> Is the documentation wrong, or is this a regression?
Try with “guile2.2-json” instead of “guile-json”.
Ludo’.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Recent change in 'guix package --search-paths' behavior?
2017-05-10 12:08 ` Ludovic Courtès
@ 2017-05-11 7:07 ` Chris Marusich
2017-05-11 8:33 ` Ludovic Courtès
0 siblings, 1 reply; 5+ messages in thread
From: Chris Marusich @ 2017-05-11 7:07 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
[-- Attachment #1.1: Type: text/plain, Size: 2259 bytes --]
Hi Ludo,
ludo@gnu.org (Ludovic Courtès) writes:
> Chris Marusich <cmmarusich@gmail.com> skribis:
>
>> Hi,
>>
>> The manual says ((guix) Invoking guix package):
>>
>> This option can also be used to compute the _combined_ search paths
>> of several profiles. Consider this example:
>>
>> $ guix package -p foo -i guile
>> $ guix package -p bar -i guile-json
>> $ guix package -p foo -p bar --search-paths
>>
>> The last command above reports about the ‘GUILE_LOAD_PATH’
>> variable, even though, taken individually, neither ‘foo’ nor ‘bar’
>> would lead to that recommendation.
>
> [...]
>
>> Is the documentation wrong, or is this a regression?
>
> Try with “guile2.2-json” instead of “guile-json”.
>
> Ludo’.
As usual, you're right! :-) That worked:
--8<---------------cut here---------------start------------->8---
[0] marusich@garuda:/tmp
$ guix package -p foo -i guile
The following package will be installed:
guile 2.2.2 /gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2
1 package in profile
The following environment variable definitions may be needed:
export PATH="foo/bin${PATH:+:}$PATH"
[0] marusich@garuda:/tmp
$ guix package -p bar -i guile2.2-json
The following package will be installed:
guile2.2-json 0.6.0 /gnu/store/a7hrfb8p7syai31rxhrcrmlq81kjcs5v-guile2.2-json-0.6.0
1 package in profile
[0] marusich@garuda:/tmp
$ guix package -p foo -p bar --search-paths
export PATH="foo/bin"
export GUILE_LOAD_PATH="bar/share/guile/site/2.2"
export GUILE_LOAD_COMPILED_PATH="bar/share/guile/site/2.2"
[0] marusich@garuda:/tmp
$
--8<---------------cut here---------------end--------------->8---
Why does 'guix' resolve to guile@2.2.2, but 'guile-json' resolves to
guile-json@0.6.0? Is it because, as mentioned in the comments in
procedure 'find-newest-available-packages' in gnu/packages.scm, "the
preferred package is whichever one was found last by 'fold-packages'"?
I've attached a patch for the documentation which might help clarify
this for anyone who has the same question in the future. What do you
think? Too much detail for an edge case, or a useful footnote?
--
Chris
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-doc-Clarify-guix-package-search-paths-example.patch --]
[-- Type: text/x-patch, Size: 1430 bytes --]
From 1b108931e88374a1835fb90dd6b0ebf715f3a267 Mon Sep 17 00:00:00 2001
From: Chris Marusich <cmmarusich@gmail.com>
Date: Wed, 10 May 2017 23:05:31 -0700
Subject: [PATCH] doc: Clarify 'guix package --search-paths' example.
* doc/guix.texi (Invoking guix package): Explain why, in some cases, a user
who runs the example code for 'guix package --search-paths' might see
different results than what is written in the manual.
---
doc/guix.texi | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/doc/guix.texi b/doc/guix.texi
index 9b2fe3fdb..57f9f7863 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -1802,7 +1802,13 @@ $ guix package -p foo -p bar --search-paths
The last command above reports about the @code{GUILE_LOAD_PATH}
variable, even though, taken individually, neither @file{foo} nor
-@file{bar} would lead to that recommendation.
+@file{bar} would lead to that recommendation@footnote{This example will
+only work as written if @code{guile-json} was built for the same major
+version of Guile that @code{guile} refers to (e.g., 2.x.x). If that is
+not the case, then this command will @emph{not} report about
+@code{GUILE_LOAD_PATH} because the two packages were built for different
+major versions of Guile. @xref{Invoking guix package}, for more
+information about how to precisely specify packages.}.
@item --profile=@var{profile}
--
2.12.2
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: Recent change in 'guix package --search-paths' behavior?
2017-05-11 7:07 ` Chris Marusich
@ 2017-05-11 8:33 ` Ludovic Courtès
2017-05-11 8:46 ` Chris Marusich
0 siblings, 1 reply; 5+ messages in thread
From: Ludovic Courtès @ 2017-05-11 8:33 UTC (permalink / raw)
To: Chris Marusich; +Cc: guix-devel
Hi Chris,
Chris Marusich <cmmarusich@gmail.com> skribis:
> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Chris Marusich <cmmarusich@gmail.com> skribis:
>>
>>> Hi,
>>>
>>> The manual says ((guix) Invoking guix package):
>>>
>>> This option can also be used to compute the _combined_ search paths
>>> of several profiles. Consider this example:
>>>
>>> $ guix package -p foo -i guile
>>> $ guix package -p bar -i guile-json
>>> $ guix package -p foo -p bar --search-paths
>>>
>>> The last command above reports about the ‘GUILE_LOAD_PATH’
>>> variable, even though, taken individually, neither ‘foo’ nor ‘bar’
>>> would lead to that recommendation.
>>
>> [...]
>>
>>> Is the documentation wrong, or is this a regression?
>>
>> Try with “guile2.2-json” instead of “guile-json”.
>>
>> Ludo’.
>
> As usual, you're right! :-) That worked:
[...]
> Why does 'guix' resolve to guile@2.2.2, but 'guile-json' resolves to
> guile-json@0.6.0?
It’s because we’re not done with the transition:
https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00436.html
The idea is to incrementally rename all “guile2.2-foo” packages to
“guile-foo”, and, when needed, keep an extra “guile2.0-foo”. For
guile-json this hasn’t been done yet, but now’s probably a good time to
do it.
> Is it because, as mentioned in the comments in procedure
> 'find-newest-available-packages' in gnu/packages.scm, "the preferred
> package is whichever one was found last by 'fold-packages'"?
>
> I've attached a patch for the documentation which might help clarify
> this for anyone who has the same question in the future. What do you
> think? Too much detail for an edge case, or a useful footnote?
I would rather not add more text to it because the example will become
valid again soonish, and the extra text might muddy waters.
WDYT?
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Recent change in 'guix package --search-paths' behavior?
2017-05-11 8:33 ` Ludovic Courtès
@ 2017-05-11 8:46 ` Chris Marusich
0 siblings, 0 replies; 5+ messages in thread
From: Chris Marusich @ 2017-05-11 8:46 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 2167 bytes --]
ludo@gnu.org (Ludovic Courtès) writes:
> Hi Chris,
>
> Chris Marusich <cmmarusich@gmail.com> skribis:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> Chris Marusich <cmmarusich@gmail.com> skribis:
>>>
>>>> Hi,
>>>>
>>>> The manual says ((guix) Invoking guix package):
>>>>
>>>> This option can also be used to compute the _combined_ search paths
>>>> of several profiles. Consider this example:
>>>>
>>>> $ guix package -p foo -i guile
>>>> $ guix package -p bar -i guile-json
>>>> $ guix package -p foo -p bar --search-paths
>>>>
>>>> The last command above reports about the ‘GUILE_LOAD_PATH’
>>>> variable, even though, taken individually, neither ‘foo’ nor ‘bar’
>>>> would lead to that recommendation.
>>>
>>> [...]
>>>
>>>> Is the documentation wrong, or is this a regression?
>>>
>>> Try with “guile2.2-json” instead of “guile-json”.
>>>
>>> Ludo’.
>>
>> As usual, you're right! :-) That worked:
>
> [...]
>
>> Why does 'guix' resolve to guile@2.2.2, but 'guile-json' resolves to
>> guile-json@0.6.0?
>
> It’s because we’re not done with the transition:
>
> https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00436.html
>
> The idea is to incrementally rename all “guile2.2-foo” packages to
> “guile-foo”, and, when needed, keep an extra “guile2.0-foo”. For
> guile-json this hasn’t been done yet, but now’s probably a good time to
> do it.
>
>> Is it because, as mentioned in the comments in procedure
>> 'find-newest-available-packages' in gnu/packages.scm, "the preferred
>> package is whichever one was found last by 'fold-packages'"?
>>
>> I've attached a patch for the documentation which might help clarify
>> this for anyone who has the same question in the future. What do you
>> think? Too much detail for an edge case, or a useful footnote?
>
> I would rather not add more text to it because the example will become
> valid again soonish, and the extra text might muddy waters.
>
> WDYT?
Yes, I agree - we don't need to explain this temporary edge case.
--
Chris
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-05-11 8:46 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-05-10 8:45 Recent change in 'guix package --search-paths' behavior? Chris Marusich
2017-05-10 12:08 ` Ludovic Courtès
2017-05-11 7:07 ` Chris Marusich
2017-05-11 8:33 ` Ludovic Courtès
2017-05-11 8:46 ` Chris Marusich
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.