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!
P.S. It's worth mentioning that when discussing with upstream, it is
unclear whether upstream will consider adding sub-directories of an ELPA
package to `load-path'. Currently there are not much such use case, and
for the existing one case of auctex it'll cause some breakage, so the
likeliness is low for now.
[1] https://lists.gnu.org/archive/html/emacs-devel/2024-05/msg00658.html
--
Xiyue Deng
Attachment:
signature.asc
Description: PGP signature