bug#42543: lint failure for packages on load path specified with -L

[Jack Hill]

Hi Ludo’! Hope you've enjoyed your (short) time away from the keyboard :)

On Wed, 5 Aug 2020, Ludovic Courtès wrote:

> Hi,
>
> Jack Hill <jackhill@jackhill.us> skribis:
>
> > jackhill@alperton ~$ guix lint -L lint-test my-hello
> > Backtrace:y-hello@2.10 [formatting]...
> >            8 (primitive-load "/home/jackhill/.config/guix/current/bi…")
> > In guix/ui.scm:
> >   1974:12  7 (run-guix-command _ . _)
> > In ice-9/boot-9.scm:
> >   1736:10  6 (with-exception-handler _ _ #:unwind? _ # _)
> > In guix/store.scm:
> >    631:22  5 (thunk)
> > In srfi/srfi-1.scm:
> >     634:9  4 (for-each #<procedure 7f40c0484020 at guix/scripts/lin…> …)
> > In guix/scripts/lint.scm:
> >      60:4  3 (run-checkers _ _ #:store _)
> > In srfi/srfi-1.scm:
> >     634:9  2 (for-each #<procedure 7f40b2ab53f0 at guix/scripts/lin…> …)
> >     241:2  1 (for-each _ _)
> > In ice-9/boot-9.scm:
> >   1669:16  0 (raise-exception _ #:continuable? _)
> >
> > ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> > In procedure for-each: Wrong type argument: #f
>
> I can’t reproduce this problem:

[…]

> $ guix lint -L /tmp/t my-hello
> $ echo $?
> 0
> $ guix show -L /tmp/t my-hello
> name: my-hello
> version: 2.10
> outputs: out
> systems: x86_64-linux i686-linux
> dependencies:
> location: /tmp/t/my-hello.scm:8:2
> homepage: https://www.gnu.org/software/hello/
> license: GPL 3+
> synopsis: Saluton, mondo GNU: ekzemplo de pako GNU
> description: GNU Hello montras la mesaĝon "Hello, world!" kaj finiĝas.  Ĝi 
> funkcias kiel ekzemplo de norma
> + kodumada tradicio de GNU.  Tiel, ĝi subtenas komand-liniajn argumentojn, 
> plurajn lingvojn, kaj tiel plu.

You've passed an absolute path to -L. Indeed, I don't don't see the 
problem when I do that, only when using a relative path. Can you try 
running `guix lint -L t my-hello` while your current working directory is 
/tmp?

> Do you still have this problem?

Yes, confirmed just now with 05f3d34094b23dc9612ff6641a0257bc4f7dcd12

> (Besides, ‘canonicalize-path’ should be used sparsely: it’s quite
> expensive and sometimes confusing for users.  With the proposed patches,
> “-L /does/not/exist” would now lead to an error.)

Perhaps this can be solved a different way. Could we propagate the 
knowledge of the current working directory, and construct absolute path 
when needed?

However, now that you, hopefully, better understand the problem, do we 
want to support relative paths passed to -L? It seems that they happen to 
work some places now, but not others (guix edit is another place where it 
doesn't work). I would be equally happy if we decided to not support 
relative paths, and warn the user when was was provided to -L.

I also think it might make sense for -L /does/not/exist to print a 
(friendly) error rather than silently not loading modules, but I'm open to 
arguments to the contrary.

Best,
Jack