From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Xiyue Deng Newsgroups: gmane.emacs.bugs Subject: bug#71817: 29.3; Sub-directory handling of ELPA package Date: Sat, 29 Jun 2024 16:32:24 -0700 Message-ID: <877ce75nqv.fsf@debian-hx90.lan> References: <875xtt8jdm.fsf@debian-hx90.lan> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15925"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 71817@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jun 30 01:34:20 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sNhaG-0003y2-Cw for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 30 Jun 2024 01:34:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sNha1-0001sS-72; Sat, 29 Jun 2024 19:34:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sNhZz-0001sF-5b for bug-gnu-emacs@gnu.org; Sat, 29 Jun 2024 19:34:03 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sNhZy-000169-Tq for bug-gnu-emacs@gnu.org; Sat, 29 Jun 2024 19:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sNhZy-0005N8-DW for bug-gnu-emacs@gnu.org; Sat, 29 Jun 2024 19:34:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Xiyue Deng Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 Jun 2024 23:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71817 X-GNU-PR-Package: emacs Original-Received: via spool by 71817-submit@debbugs.gnu.org id=B71817.171970401520615 (code B ref 71817); Sat, 29 Jun 2024 23:34:02 +0000 Original-Received: (at 71817) by debbugs.gnu.org; 29 Jun 2024 23:33:35 +0000 Original-Received: from localhost ([127.0.0.1]:54139 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sNhZW-0005MR-Nx for submit@debbugs.gnu.org; Sat, 29 Jun 2024 19:33:35 -0400 Original-Received: from mail-il1-f172.google.com ([209.85.166.172]:50394) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sNhZV-0005ME-1b for 71817@debbugs.gnu.org; Sat, 29 Jun 2024 19:33:33 -0400 Original-Received: by mail-il1-f172.google.com with SMTP id e9e14a558f8ab-375858224adso8729745ab.0 for <71817@debbugs.gnu.org>; Sat, 29 Jun 2024 16:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719703947; x=1720308747; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=ZgUI8tLlt5dqnKrCdWYh755caCTxw7fhDXnPvb3wOkw=; b=D7gh6RDB/R5CkyHLnx3BFebgt+i2560AtjORojIltrXb5ZcT7d3KnNvH9Ty1CfhNZh IeBvrBT6KQFDsLjw3dMjvocCSYmXSQHD4eNKlEvXwi4dp6RlYB0Jpk+VBdX7iWBdOXVJ a/GOy/LCrJXSkjbvnKjlEwh3+uiizc1DeZqOgZLvT1mh3YPTF5uJHSKsChjh76eYdRke qBnN/xPvTvM1UD7hmCqNFT5eW2svAmvoPP95RTPQC3OlRJDc9obBJM9864pJmPv1G7op e5b86eWX0GNA8vNfY3QfB8GWEmhxOfBoYkgRSWMXL/4fqYeRFroL8Q4jTGx+l9FjTTY4 j/1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719703947; x=1720308747; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ZgUI8tLlt5dqnKrCdWYh755caCTxw7fhDXnPvb3wOkw=; b=k8NtSKg9DHQzZ8cvogEBHiU2aAHK5/DDBeDg+jm6qM7md72Ty3CsitTNkNzZivxsF6 de9i4FIbYzfQ0l2uzZJIoKLbaFCE6s8VoSZ8qXXveukEPmDWOF3rhT7s3l9Yr8zYJB0l Qz5UNy39sW1WSjKeizgy2z8z6r05t1RP4vnFc+A8v/fDOUJi7J1S2BJf6iyJ6rmKuEh0 jRM7u6LN5+W6VdE/UsMo7Zk2nlzeLUcj+bUc25AZgldxals5hbPpk0F0tFa6LzBFsGW5 ijoUC294J5EmCX7i08flhcjYf8OCmCMQyffOhaYUoRNPUIJNQmvh1xspw7KOlc7Y8B81 49IQ== X-Gm-Message-State: AOJu0YyuRKye4FyFZvBBaP491MDyCBCcr6N5sZQptdPqP6X3Xl29NwNM jLEHYEv3H59KrL8MSxiDUFvHfK94vk4SoYKvkJo1ZRBhq7NKTfWThDux+5SDyEcD8Q== X-Google-Smtp-Source: AGHT+IHSyI9UUuoxuH2E8FvtwsDHf8jXFQ+qB9kh/H/bwSJWixDBkj4SYsKQEhCGXWQbSIdbxuCaSw== X-Received: by 2002:a05:6e02:b2c:b0:376:1cf6:6be4 with SMTP id e9e14a558f8ab-37cd0ee0199mr25938255ab.14.1719703945441; Sat, 29 Jun 2024 16:32:25 -0700 (PDT) Original-Received: from debian-hx90 ([2603:8000:a400:cdc:9e7a:da57:565:c768]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1fac10d20c1sm37318025ad.30.2024.06.29.16.32.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 29 Jun 2024 16:32:25 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Fri, 28 Jun 2024 09:26:55 -0400") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:288138 Archived-At: Stefan Monnier 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