Re: Subdirectories in GUIX_PACKAGE_PATH

[Ludovic Courtès]

Hi Alex,

Alex Kost <address@hidden> skribis:

> Ludovic Courtès (2017-06-30 11:35 +0200) wrote:

[...]

>>> Looks like this was removed in an attempt to improve performance over
>>> NFS.  The “scheme-files” procedure now includes a comment:
>>>
>>>   ;; XXX: We don't recurse if we find a symlink.
>>>
>>> Would it not be better to fix this instead of adding support for special
>>> syntax in GUIX_PACKAGE_PATH?
>>
>> Indeed, apologies for the breakage.
>>
>> I think the patch below fixes it.  It incurs overhead only when a
>> symlink is encountered, which is reasonable I think.
>>
>> Chris & Alex: could you give it a try and report back?
>
> I confirm that the patch you attached fixes this problem, thanks!

Great, committed with a test as
960c6ce96d746cf19829ad26e092ec5dad2a5c62.

> I have a (probably not related) question though: in the past, package
> 'location' contained an *absolute* file name for the packages from
> GUIX_PACKAGE_PATH.  Now these locations are *relative* file names.  Is
> this intended?
>
> If so, this is a problem for Emacs-Guix: you see, when you try to open a
> package location (for example, by pressing an according button in *Guix
> Package Info* buffer), it is expanded against 'guix-directory' variable.
> So if you open "gnu/packages/guile.scm" location, it works, but now if
> it is your location like "my-guix-packages/foo.scm", the wrong
> (non-existent) file will be opened.  Previously it worked, because that
> location was absolute, like "/home/me/my-guix-packages/foo.scm".

I’ve noticed this but I didn’t think it was a regression.

Basically Guile supports two “file name canonicalization” modes: one
that returns a file name relative to %load-path, and one that returns an
absolute file name.  By default, when loading modules, we’re in
‘relative’ mode; this is so that modules can be moved on disk and don’t
record their initial location.

I think the last time this was changed was a year ago in
14d5ca2e2e57643b6b4acfb980b18b7474c27e7b.

Thanks,
Ludo’.