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.devel Subject: Re: Question regarding load-path handling for ELPA packages Date: Wed, 22 May 2024 18:42:38 -0700 Message-ID: <87zfshxq0h.fsf@debian-hx90.lan> References: <878r0ifjmt.fsf@debian-hx90.lan> <87eda0765g.fsf@debian-hx90.lan> <87o794z6l8.fsf@web.de> <87a5ko6s64.fsf@debian-hx90.lan> <87bk53cfo2.fsf@web.de> <87h6eu5kfa.fsf@debian-hx90.lan> <87jzjpsgsw.fsf@web.de> <87ikz93tlh.fsf@debian-hx90.lan> <87bk4xvo5j.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18179"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Michael Heerdegen via "Emacs development discussions." To: Michael Heerdegen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 23 03:43:49 2024 Return-path: Envelope-to: ged-emacs-devel@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 1s9xUi-0004b3-Q9 for ged-emacs-devel@m.gmane-mx.org; Thu, 23 May 2024 03:43:48 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s9xTk-00088r-U6; Wed, 22 May 2024 21:42:48 -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 1s9xTj-00088e-Fg for emacs-devel@gnu.org; Wed, 22 May 2024 21:42:47 -0400 Original-Received: from mail-pl1-x631.google.com ([2607:f8b0:4864:20::631]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s9xTe-0000N3-JP for emacs-devel@gnu.org; Wed, 22 May 2024 21:42:47 -0400 Original-Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1eca195a7c8so115878695ad.2 for ; Wed, 22 May 2024 18:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716428560; x=1717033360; darn=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=uaY43KWNrLMsUCFL+mKqnQEoO7WzjERApKz0lYMTJH8=; b=RfFytIMXJiO7BModdodPOCzYiJvOFV3AFXpr6IP8joVIv/LKzSm+njOuKOAm61eRT9 y930dexb4jNuK2/hObXQzs267Ko+Shz409Z5s7D54xjZxsHadiQ3XKqGmHGdgiFDiJSU T1qlNQgMiSOr93eVjxUGQd6nSHJwpmU4UZE8fiCWQaAQZ7GDu/eZoZi9uM6sce+ghnY/ kFvhnxGzBOyjq9FNzhWwl85xrQrqYSrspz/0Ezdl7u687jLeX9TDwTuGQe7rxoXohN7v Cgxt3kFmFjQejv0OMC2/vukt/taP4XgmGwSpP8c7+1qAtDDtBcO4HAmFi08fLn1Nfr5M wpQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716428560; x=1717033360; 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=uaY43KWNrLMsUCFL+mKqnQEoO7WzjERApKz0lYMTJH8=; b=dBwVsO6T7f+C4VnoV05hqUo4CJwH+e7+Mila5P9WBVZvwSARYw46OtYxcNeWvp3rS7 UnYe4niQBQea4bfhF8RuVFWpCMRUczDrTJFlRoaozYW6Yzz6a2qrRDIbHRiPCeR1cNzw hPmVW7njcw24xGq2/EGwLWIrGp1YyCAC5KC74H2wlVnGu9KZarfMh0qIlT/M3xp5Lflv JUipewR9otuZQUkdX9JZLV+V3zNPYEyFKUbjgbWNg3oehaviEIdQgVYMd96BNvgpsdRP YvlpWdkBIn10Q1qcgDGaivQ1vY1jhwCgSQ2ORGJy61sYUKBg8/O1bEFoQGFlbRloG8B8 6DLw== X-Gm-Message-State: AOJu0Yx3HRegKRSfNifvNgrtZJI2fM7P447/+ZO0q/Tr4qzqNGr1fW5M KN5akCw5/jqurLBozh6+KxFcFWS/nDsPuipVklcjiT4bSYifYSJFuYbjoQ== X-Google-Smtp-Source: AGHT+IEd6iFf0g1Qjj2EBb7ojjr6Z3n6SHd7V2bHE1j7voF2kW8+rIO8XgxGEx6YV/rN1vbg4Ds4FQ== X-Received: by 2002:a17:903:2cc:b0:1f3:d38:a99 with SMTP id d9443c01a7336-1f31c94cd60mr38132655ad.10.1716428560424; Wed, 22 May 2024 18:42:40 -0700 (PDT) Original-Received: from debian-hx90 ([2603:8000:a400:cdc:b92e:12bb:3385:46a9]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1f2f072b1c6sm82172785ad.308.2024.05.22.18.42.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 May 2024 18:42:39 -0700 (PDT) In-Reply-To: <87bk4xvo5j.fsf@web.de> (Michael Heerdegen's message of "Wed, 22 May 2024 17:53:28 +0200") Received-SPF: pass client-ip=2607:f8b0:4864:20::631; envelope-from=manphiz@gmail.com; helo=mail-pl1-x631.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:319492 Archived-At: Michael Heerdegen writes: > Xiyue Deng writes: > >> Thanks for your expanded explanations and code pointers! It helped me a >> lot in understanding how package.el handles `load-path'. After some >> more investigation, it turns out the behavior I observe in dh-elpa >> installation path is actually a result of the existence of subdirs.el in >> its parent directory. I have added an extended explanations in the >> Debian tracking bug[1]. > > I didn't investigate that much - but AFAIU > `normal-top-level-add-to-load-path' doesn't add subdirectories > recursively. Or does it? > This is the content of subdirs.el: ,---- | (if (fboundp 'normal-top-level-add-subdirs-to-load-path) | (normal-top-level-add-subdirs-to-load-path)) `---- So looks like it does :) > And - we are lucky and I'm on Debian, so I can have a look. > > On my stable branch system, an emacs installation with package "auctex" > installed will not have subdirectories of auctex stuff installed. After > startup I only see "/usr/share/emacs/site-lisp/auctex" and > "/usr/share/auctex" in `load-path'. Or does your problem occur in > experimental only? > (This part is mostly Debian centric.) Sorry I wasn't very clear about the auctex status. As a matter of fact, the current auctex is not yet Elpafied, so while it's usable, its current installation is not detected by package.el so that if you use `(use-package auctex :ensure t)' it will install a separate auctex from ELPA (see tracking bug[1]). On the other hand, I am experimenting an attempt to Elpafy auctex[2] based on the recursive byte-compiling which I'm also experimenting on dh-elpa and is mostly ready[3], with your help here. With this support dh-elpa can keep the same directory layout as ELPA for package with source files in nested directories as well. >> I think one last question I'd like to ask is the direction of >> subdirectory handling in ELPA packages. Though currently the case of >> auctex may cause breakage, this is in the minority and hence fixing it >> can be localized to just one package, while there may be benefits to do >> so for other cases. > > What would those benefits be? > > Note that subdirectories may contain random stuff like test files not to > be intended to be loaded for normal functioning at all. It's not a > problem to keep the "normal" source code files in the top-level > directory - there is room enough there... And keeping load-path small > makes lookup faster. We may add a lot of unnecessary crap. Things > would also get harder to investigate with load-path complicated in such > a way. Any package still can add subdirectories explicitly. In sum I > see more disadvantages. I agree with you arguments here. My initial thoughts for adding subdirectories are mainly to give developer some flexibilities to organize the source code, but if subdirectories can be added explicitly then it's fine. Do you know where how that's done is documented for ELPA? > > Michael. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056939 [2] https://salsa.debian.org/manphiz/auctex/-/tree/elpafy-new?ref_type=heads [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069210 -- Xiyue Deng