unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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





  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).