Xiyue Deng <manphiz@gmail.com> writes:
> Xiyue Deng <manphiz@gmail.com> writes:
>
>> Currently there is a behavior difference between elpafied packages and
>> upstream ELPA packages on `load-path' handling: for elpafied packages,
>> all nested directories are added to `load-path', while for upstream ELPA
>> only the root directory is added. Normally this should not be an issue,
>> but when trying to elpafy auctex, it's nested directory "style/"
>> contains many modules whose names collide with standard modules and
>> hence broken Eglot. This sounds like a bad practice of the package, but
>> it would still be good to match upstream behavior so as to minimize
>> surprises. Will try to figure this out.
>
> Well it took me quite a while to realize what's going on.
>
> Initially I thought there were some handling in package.el that somehow
> treated the dh-elpa installation path differently than
> `package-user-dir'. With extensive code search regarding `load-path',
> `package-directory-list', `package-user-dir', as well as other relevant
> functions/variables, and I even tried to consult on
> emacs-devel@gnu.org[1] where Michael gave multiple suggestions and
> pointers, still I didn't find anything.
>
> Well, not until I tried to search for `load-path' in the whole Emacs
> source when I noticed the function
> `normal-top-level-add-subdirs-to-load-path', which were added to a
> `subdirs.el' file which does what its name suggests. Then it didn't
> take long for me I to find the file
> `/usr/share/emacs/site-lisp/subdirs.el', and the mystery is solved: this
> file causes all the sub-directories of the directory with this file
> being added to `load-path', including everything under the dh-elpa
> installation path `elpa{,-src}'.
>
> So, this means that as long as dh-elpa uses
> `/usr/share/emacs/site-lisp/elpa{,-src}' as the installation path for
> elpafied packages, all its subdirectories will be added to `load-path'
> automatically, which is currently different with how package.el handles
> ELPA package - it only adds the path holding the *-autoloads.el file to
> `load-path'.
>
> Right now I think there are two obvious directions forward:
>
> * Move elpa{,-src} out of the path with a subdirs.el file, which means
> it should not use `/usr/share/emacs/site-lisp/elpa{,-src}', but
> something like `/usr/share/emacs/elpa{,-src}' or
> `/usr/share/emacs/${version}/elpa{,-src}'. This would mean a big
> migration for all elpafied packages due to the directory change.
>
> - With the current ongoing discussion on fixing the loading /
> configuration dependencies, a migration may happen anyway, so
> probably both can be done?
>
> * Patch the generated subdirs.el to skip any elpa{,-src} directories.
> I don't expect that upstream will accept such a change, so we'll
> probably have to carry this patch, which would not be ideal anyway.
>
> There may be other ways. Any advices are welcome!
>
So it looks like `normal-top-level-add-subdirs-to-load-path' has a
special handling that ignores directories with a `.nosearch' file. I
have added that to both elpa{,-src} and it seems to work as intended.
So the next question is how/when to add those files. Continuing to
experiment.
--
Xiyue Deng
Attachment:
signature.asc
Description: PGP signature