GNU bug report logs - #34590
Effects of GUIX_PACKAGE_PATH and --load-path differ

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 34590 in the body.
You can then email your comments to 34590 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Daniel Gerber <dg <at> atufi.org>
To: bug-guix <at> gnu.org
Subject: Effects of GUIX_PACKAGE_PATH and --load-path differ
Date: Wed, 20 Feb 2019 11:38:19 +0100

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 <at> 1.24.0 in the guix channel (a37bdf4) 
and libuv <at> 1.26.0 in --and also node <at> 11.10.0 only in-- 
/gnu/guix-local-packages/:

$ export GUIX_PACKAGE_PATH=/gnu/guix-local-packages/; guix 
environment --no-grafts -C node <at> 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 <at> 11.10.0 --ad-hoc 
strace gdb -- ls /gnu/store/ |grep -o libuv-.*
libuv-1.24.0

Is this the intended behaviour?

Message #8 received at 34590 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Daniel Gerber <dg <at> atufi.org>
Cc: 34590 <at> debbugs.gnu.org
Subject: Re: bug#34590: Effects of GUIX_PACKAGE_PATH and --load-path differ
Date: Wed, 06 Mar 2019 14:38:11 +0100

Hi Daniel,

Daniel Gerber <dg <at> atufi.org> skribis:

> 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 <at> 1.24.0 in the guix channel (a37bdf4) and libuv <at> 1.26.0 in --and also node <at> 11.10.0 only in-- 
> /gnu/guix-local-packages/:
>
> $ export GUIX_PACKAGE_PATH=/gnu/guix-local-packages/; guix environment
> --no-grafts -C node <at> 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 <at> 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 <at> 11.10.0?

Then my guess is that “node <at> 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’.

Message #11 received at 34590 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Gerber <dg <at> atufi.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 34590 <at> debbugs.gnu.org
Subject: Re: bug#34590: Effects of GUIX_PACKAGE_PATH and --load-path differ
Date: Wed, 06 Mar 2019 15:43:41 +0100

Hi,  2019-03-06, Ludovic Courtès: 

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

Yes, it provides node <at> 11.10.0 *plus* its dependency libuv <at> 1.26.0. 

 $ tree /gnu/guix-local-packages/ /gnu/guix-local-packages/ ├── 
 gnu │   └── packages │       ├── libevent.scm │       └── 
 node.scm └── node-llhttp.patch 

> Then my guess is that “node <at> 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
--

Message #14 received at 34590 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Daniel Gerber <dg <at> atufi.org>
Cc: 34590 <at> debbugs.gnu.org
Subject: Re: bug#34590: Effects of GUIX_PACKAGE_PATH and --load-path differ
Date: Wed, 06 Mar 2019 18:49:09 +0100

Hi,

Daniel Gerber <dg <at> atufi.org> skribis:

>> However, what do /gnu/guix-local-packages/ contain?  I suppose it
>> provides node <at> 11.10.0? 
>
> Yes, it provides node <at> 11.10.0 *plus* its dependency libuv <at> 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’.

Message #17 received at 34590 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Gerber <dg <at> atufi.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 34590 <at> debbugs.gnu.org
Subject: Re: bug#34590: Effects of GUIX_PACKAGE_PATH and --load-path differ
Date: Thu, 07 Mar 2019 09:01:55 +0100

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
--

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.