Effects of GUIX_PACKAGE_PATH and --load-path differ

DoneSubmitted by Daniel Gerber.
Details
2 participants
  • Daniel Gerber
  • Ludovic Courtès
Owner
unassigned
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 pathorder would differ.
However, what do /gnu/guix-local-packages/ contain? I suppose itprovides 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-deterministicfashion.
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 Igot 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 canbe only one (gnu packages node) module at run time.
It may be that GUIX_PACKAGE_PATH and -L lead to a different (gnupackages node) being loaded first, but really the core of the problemIMO is the module name collision.
So my suggestion would be to rename your modules to, say, (danielpackages …); 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 notabugclose 34590
?
Your comment

This issue is archived.

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