bug#17467: 24.3; locate-library returning spurious path

[Alex Kosorukoff <alex@3form.com>]

[-- Attachment #1: Type: text/plain, Size: 2244 bytes --]

On Thu, May 15, 2014 at 12:39 PM, Stefan Monnier
<monnier@iro.umontreal.ca>wrote:

> > locate-library incorrectly generates a set of suffixes to extend the
> > base library name (".elc" ".elc.gz" ".el" ".el.gz" "" ".gz"), while it
> > should be just (".elc" ".elc.gz" ".el" ".el.gz") when nosuffix is
> > nil.
>
> FWIW, this simply reflects what `load' does, so changing it in
> `locate-library' would mean that it doesn't do what `load' does, which
> I would count as a bug.
>

I agree with you that locate library should do what load does.


> The main issue I see is that `load' includes a `must-suffix' argument
> which provides the behavior you're looking for (and which is used by
> `require') whereas locate-library doesn't provide it.
>
> > This leads to spurious paths found, like name.gz. I found
> > this issue because (locate-library "tramp") was returning
> > "/home/alex/.emacs.d/trump" not "../lisp/net/trum.elc". The workaround
> > is (locate-file "tramp" load-path (get-load-suffixes))
>
> IIUC the problem you had was with `load' rather than with
> `locate-library', so I think what this boils down to is that the `load'
> that looks for `trump' should be changed to provide `must-suffix'.
> WDYT?
>

In fact, I was looking for a function that would locate library and return
the path to it, so I could compile the explicit path into .elc file that
will avoid searching load-path and save time when it is run. locate-library
seems like a perfect tool for this purpose, but turned out to be not as
useful as it sounds because it is not currently capable of correctly
reproducing search behavior of load or require. As a result, I switched to
locate-file. This currently seems to be the only reliable way to find
correct paths to libraries. I think we could make locate-library more
useful by extending it in one of two possible ways. It can either accept
symbol argument as well as string and behave exactly like require does in
this case (currently it will just fail with error if given a symbol). An
alternative way is to add an optional must-suffix argument to make it
consistent with load. Both ways will keep it backward compatible and will
allow it to emulate the logic of both load and require.


>
>
>         Stefan
>

[-- Attachment #2: Type: text/html, Size: 3296 bytes --]