GNU bug report logs - #71817
29.3; Sub-directory handling of ELPA package

Previous Next

Package: emacs;

Reported by: Xiyue Deng <manphiz <at> gmail.com>

Date: Fri, 28 Jun 2024 10:15:02 UTC

Severity: normal

Merged with 71789

Found in version 29.3

Full log


Message #8 received at 71817 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Xiyue Deng <manphiz <at> gmail.com>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 71817 <at> debbugs.gnu.org
Subject: Re: bug#71817: 29.3; Sub-directory handling of ELPA package
Date: Fri, 28 Jun 2024 14:19:28 +0300
> From: Xiyue Deng <manphiz <at> gmail.com>
> Date: Fri, 28 Jun 2024 03:13:57 -0700
> 
> I'm opening a bug to continue the discussion from the emacs-devel
> mailing list thread[1].
> 
> TL;DR I would like to understand how upstream would like to handle
> sub-directories with ELisp source files as to whether to add them to
> `load-path' recursively or not to determine the path forward for source
> code organization.
> 
> 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):
> 
> ,----
> | ~/.config/emacs/elpa/elpafoo/
> | ~/.config/emacs/elpa/elpafoo/elpafoo.el
> | ~/.config/emacs/elpa/elpafoo/elpabar
> | ~/.config/emacs/elpa/elpafoo/elpabar/elpabar.el
> `----
> 
> only `~/.config/emacs/elpa/elpafoo' is added to `load-path', while both
> elpafoo.el and elpabar.el will get byte-compiled.  Currently I don't
> seem to find where this behavior is documented, so do give me a pointer
> if it exists.
> 
> If this is not yet a policy, I wonder whether this will be the path
> forward for `load-path' handling.  I see some pros of adding
> sub-directories recursively, such as better source code organization so
> that not all source code files need to reside in the root directory.
> However, the downside is also obvious, such as unnecessary loading of
> test sources as Michael pointed out in [2], or loading vendored code
> that could cause conflicts (as I observed in the case of auctex), etc.
> 
> So, what would be the upstream or package.el maintainers' opinions on
> how this should be handled?
> 
> Thanks in advance.
> 
> [1] https://lists.gnu.org/archive/html/emacs-devel/2024-05/msg00658.html
> [2] https://lists.gnu.org/archive/html/emacs-devel/2024-05/msg01039.html

Adding Stefan.




This bug report was last modified 349 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.