Effects of GUIX_PACKAGE_PATH and --load-path differ

  • Done
  • quality assurance status badge
Details
2 participants
  • Daniel Gerber
  • Ludovic Courtès
Owner
unassigned
Submitted by
Daniel Gerber
Severity
normal
D
D
Daniel Gerber wrote on 20 Feb 2019 11:38
(address . bug-guix@gnu.org)
8736oivj6s.fsf@atufi.org
Hi,

From reading the doc on `guix environment`:

-L, --load-path=DIR prepend DIR to the package module search
path

I would expect these to be exactly equivalent:

$ export GUIX_PACKAGE_PATH=; guix environment -L path ...
$ export GUIX_PACKAGE_PATH=path; guix environment ...

Yet they differ. With libuv@1.24.0 in the guix channel (a37bdf4)
and libuv@1.26.0 in --and also node@11.10.0 only in--
/gnu/guix-local-packages/:

$ export GUIX_PACKAGE_PATH=/gnu/guix-local-packages/; guix
environment --no-grafts -C node@11.10.0 --ad-hoc strace gdb -- ls
/gnu/store/ |grep -o libuv-.*
libuv-1.26.0

$ export GUIX_PACKAGE_PATH=; guix environment -L
/gnu/guix-local-packages/ --no-grafts -C node@11.10.0 --ad-hoc
strace gdb -- ls /gnu/store/ |grep -o libuv-.*
libuv-1.24.0

Is this the intended behaviour?
L
L
Ludovic Courtès wrote on 6 Mar 2019 14:38
(name . Daniel Gerber)(address . dg@atufi.org)(address . 34590@debbugs.gnu.org)
87lg1si0n0.fsf@gnu.org
Hi Daniel,

Daniel Gerber <dg@atufi.org> skribis:

Toggle quote (24 lines)
> From reading the doc on `guix environment`:
>
> -L, --load-path=DIR prepend DIR to the package module search path
>
> I would expect these to be exactly equivalent:
>
> $ export GUIX_PACKAGE_PATH=; guix environment -L path ...
> $ export GUIX_PACKAGE_PATH=path; guix environment ...
>
> Yet they differ. With libuv@1.24.0 in the guix channel (a37bdf4) and libuv@1.26.0 in --and also node@11.10.0 only in--
> /gnu/guix-local-packages/:
>
> $ export GUIX_PACKAGE_PATH=/gnu/guix-local-packages/; guix environment
> --no-grafts -C node@11.10.0 --ad-hoc strace gdb -- ls /gnu/store/
> |grep -o libuv-.*
> libuv-1.26.0
>
> $ export GUIX_PACKAGE_PATH=; guix environment -L
> /gnu/guix-local-packages/ --no-grafts -C node@11.10.0 --ad-hoc strace
> gdb -- ls /gnu/store/ |grep -o libuv-.*
> libuv-1.24.0
>
> Is this the intended behaviour?

Probably not.

I experimented a bit and couldn’t find any evidence that the search path
order would differ.

However, what do /gnu/guix-local-packages/ contain? I suppose it
provides node@11.10.0?

Then my guess is that “node@11.10.0” is ambiguous and that
‘specification->package’ chooses one of the two in a non-deterministic
fashion.

Can you show the output of:

guix package -A node
guix package -A node -L /gnu/guix-local-packages
GUIX_PACKAGE_PATH=/gnu/guix-local-packages guix package -A node

?

TIA,
Ludo’.
D
D
Daniel Gerber wrote on 6 Mar 2019 15:43
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 34590@debbugs.gnu.org)
87h8cg3vxe.fsf@atufi.org
Hi, 2019-03-06, Ludovic Courtès:

Toggle quote (3 lines)
> However, what do /gnu/guix-local-packages/ contain? I suppose
> it provides node@11.10.0?

Yes, it provides node@11.10.0 *plus* its dependency libuv@1.26.0.

$ tree /gnu/guix-local-packages/ /gnu/guix-local-packages/ ???
gnu ?   ??? packages ?   ??? libevent.scm ?   ???
node.scm ??? node-llhttp.patch
Toggle quote (11 lines)
> Then my guess is that “node@11.10.0” is ambiguous and that
> ‘specification->package’ chooses one of the two in a
> non-deterministic fashion.
>
> Can you show the output of:
>
> guix package -A node guix package -A node -L
> /gnu/guix-local-packages
> GUIX_PACKAGE_PATH=/gnu/guix-local-packages guix package -A
> node

$ guix package -A '^(node|libuv)' libuv 1.24.0 out
gnu/packages/libevent.scm:125:2 libuv 1.19.2 out
gnu/packages/libevent.scm:159:2 node 9.11.1 out
gnu/packages/node.scm:46:2 node-lts 8.12.0 out
gnu/packages/node.scm:202:2
$ guix package -A '^(node|libuv)' -L /gnu/guix-local-packages
;;; note: source file
/gnu/guix-local-packages/gnu/packages/libevent.scm ;;;
newer than compiled
/gnu/store/l6wkk4kzhvkg014slv3plx513cgxqx6h-guix-module-union/lib/guile/2.2/site-ccache/gnu/packages/libevent.go
;;; note: source file
/gnu/guix-local-packages/gnu/packages/node.scm ;;; newer
than compiled
/gnu/store/l6wkk4kzhvkg014slv3plx513cgxqx6h-guix-module-union/lib/guile/2.2/site-ccache/gnu/packages/node.go
libuv 1.19.2 out
/gnu/guix-local-packages/gnu/packages/libevent.scm:159:2 libuv
1.26.0 out
/gnu/guix-local-packages/gnu/packages/libevent.scm:125:2 node
11.10.0 out
/gnu/guix-local-packages/gnu/packages/node.scm:46:2 node-lts
8.12.0 out
/gnu/guix-local-packages/gnu/packages/node.scm:185:2
$ GUIX_PACKAGE_PATH=/gnu/guix-local-packages guix package -A
'^(node|libuv)' ;;; note: source file
/gnu/guix-local-packages/gnu/packages/libevent.scm ;;;
newer than compiled
/gnu/store/l6wkk4kzhvkg014slv3plx513cgxqx6h-guix-module-union/lib/guile/2.2/site-ccache/gnu/packages/libevent.go
;;; note: source file
/gnu/guix-local-packages/gnu/packages/node.scm ;;; newer
than compiled
/gnu/store/l6wkk4kzhvkg014slv3plx513cgxqx6h-guix-module-union/lib/guile/2.2/site-ccache/gnu/packages/node.go
libuv 1.26.0 out
/gnu/guix-local-packages/gnu/packages/libevent.scm:125:2 libuv
1.19.2 out
/gnu/guix-local-packages/gnu/packages/libevent.scm:159:2 node
11.10.0 out
/gnu/guix-local-packages/gnu/packages/node.scm:46:2 node-lts
8.12.0 out
/gnu/guix-local-packages/gnu/packages/node.scm:185:2
I note the order of libuv packages varies, but versions are
correct. Also, should one worry about the "source newer than
compiled" messages? I presumed the cached .go files come from the
official channel, hence older than the sources in
/gnu/guix-local-packages.


--
Daniel Gerber
--
L
L
Ludovic Courtès wrote on 6 Mar 2019 18:49
(name . Daniel Gerber)(address . dg@atufi.org)(address . 34590@debbugs.gnu.org)
8736nzgaga.fsf@gnu.org
Hi,

Daniel Gerber <dg@atufi.org> skribis:

Toggle quote (9 lines)
>> However, what do /gnu/guix-local-packages/ contain? I suppose it
>> provides node@11.10.0?
>
> Yes, it provides node@11.10.0 *plus* its dependency libuv@1.26.0.
>
> $ tree /gnu/guix-local-packages/ /gnu/guix-local-packages/ ??? gnu
> ?   ??? packages ?   ??? libevent.scm ?   ??? node.scm ???
> node-llhttp.patch

(Looks like your email client automatically splits lines, but I think I
got the above tree right.)

Your local packages use the same module names as those in Guix itself:
(gnu packages …).

You should not do that because modules are unique. That is, there can
be only one (gnu packages node) module at run time.

It may be that GUIX_PACKAGE_PATH and -L lead to a different (gnu
packages node) being loaded first, but really the core of the problem
IMO is the module name collision.

So my suggestion would be to rename your modules to, say, (daniel
packages …); remember to “mv gnu daniel” as well.

Let me know if that solves the problem!

Thanks,
Ludo’.
D
D
Daniel Gerber wrote on 7 Mar 2019 09:01
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 34590@debbugs.gnu.org)
87pnr3ru30.fsf@atufi.org
I see, then I'll need another workflow to hack on gnu packages --
either rename them or maintain a local branch/channel for guix and
build with ./pre-inst-env.

That should solve it, thanks!

--
Daniel Gerber
--
L
L
Ludovic Courtès wrote on 8 Mar 2019 12:36
control message for bug #34590
(address . control@debbugs.gnu.org)
87ftrxha2y.fsf@gnu.org
tags 34590 notabug
close 34590
?
Your comment

This issue is archived.

To comment on this conversation send an email to 34590@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 34590
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch