From: Xiyue Deng <manphiz@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 71817@debbugs.gnu.org
Subject: bug#71817: 29.3; Sub-directory handling of ELPA package
Date: Sat, 29 Jun 2024 16:32:24 -0700 [thread overview]
Message-ID: <877ce75nqv.fsf@debian-hx90.lan> (raw)
In-Reply-To: <jwvsewxw6w1.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Fri, 28 Jun 2024 09:26:55 -0400")
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Currently as observed, ELPA packages only get their root path added to
>> `load-path', but source code in sub-directories will still get
>> byte-compiled. That is, for an ELPA package elpafoo with a nested
>> sub-directory of the following structure (installed through package.el):
>
> The recursive compilation is somewhat of an "accident": it was the
> easiest to implement (and seemed like a good idea anyway).
>
> The `load-path` behavior is conscious: it's easy for a package to add
> more subdirectories to the `load-path` but it would be much harder to
> remove undesired ones. [ And of course, the current behavior is also
> the easiest one to implement. ]
>
>> If this is not yet a policy, I wonder whether this will be the path
>> forward for `load-path' handling.
>
> In `elpafoo.el`, include something like:
>
> ;;;###autoload
> (add-to-list 'load-path
> (expand-file-name
> "elpabar" (file-name-directory load-file-name)))
>
> This assumes that you want `elpabar` to be in your `load-path` right
> from the start (i.e. that an entry point to your package is in the
> `elpabar` subdirectory). If `elpabar` can only ever be used from code
> that's in the `elpafoo` directory, there are other options (such as
> `(require 'elpabar/elpabar)` or using an auxiliary `elpafoo-loaddefs.el`
> which you load when `elpafoo.el` is loaded, ...
>
>> I see some pros of adding sub-directories recursively,
>
> I don't. Most of the packages which use subdirectories have a complex
> enough layout that some of those directories should not be in
> `load-path`: it's better to let them add entries "manually" at the
> appropriate time than to try and do it automatically.
>
> The more real problem is that the way `elpafoo-autoloads.el` is created
> does *not* scan ELisp files in subdirectories. The way this is handled
> typically in that the ELPA tarball comes with its own
> `elpabar/elpabar-autoloads.el` file and `elpafoo.el` then needs to
> contain something like
>
> ;;;###autoload
> (require 'elpabar/elpabar-autoloads)
>
> The main downside here is that the current elpa.gnu.org scripts don't
> know how to build such a `elpabar/elpabar-autoloads.el`, so you either
> need to store it in the Git (which is ugly since it's a generated file),
> or use an ad-hoc `:make` rule.
>
> IMO we should change the ELPA protocol so that the
> `elpafoo-autoloads.el` is not created during installation but is instead
> included in the tarball, so it can be generated any way we like.
>
>
> Stefan
>
Thanks for the explanations and for exploring options to load sources in
sub-directories without recursive loading by default. I take that the
current status - byte-compile recursively, only add source root path to
`load-path' - will continue to be the path forward.
For now, it makes sense that loading sources from sub-directories
requires some manual `load-path' handling. Maybe when using
sub-directories to organize source files becomes more common upstream
may consider adding some convenient functions/macros to make it easier,
but it will be for the future.
Thanks again!
--
Xiyue Deng
next prev parent reply other threads:[~2024-06-29 23:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-28 10:13 bug#71817: 29.3; Sub-directory handling of ELPA package Xiyue Deng
2024-06-28 11:19 ` Eli Zaretskii
2024-06-28 13:26 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-29 23:32 ` Xiyue Deng [this message]
2024-06-30 3:26 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877ce75nqv.fsf@debian-hx90.lan \
--to=manphiz@gmail.com \
--cc=71817@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).