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: Question regarding load-path handling for ELPA packages Date: Thu, 09 May 2024 20:09:14 -0700 Message-ID: <878r0ifjmt.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="701"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 10 05:10:15 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 1s5GeE-000AXR-QQ for ged-emacs-devel@m.gmane-mx.org; Fri, 10 May 2024 05:10:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s5GdN-0001jn-Vc; Thu, 09 May 2024 23:09:21 -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 1s5GdL-0001jZ-QR for emacs-devel@gnu.org; Thu, 09 May 2024 23:09:19 -0400 Original-Received: from mail-pl1-x62e.google.com ([2607:f8b0:4864:20::62e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s5GdK-0008JP-49 for emacs-devel@gnu.org; Thu, 09 May 2024 23:09:19 -0400 Original-Received: by mail-pl1-x62e.google.com with SMTP id d9443c01a7336-1edc696df2bso12948835ad.0 for ; Thu, 09 May 2024 20:09:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715310556; x=1715915356; darn=gnu.org; h=mime-version:user-agent:message-id:date:subject:to:from:from:to:cc :subject:date:message-id:reply-to; bh=Njm5K/OzxKfcDwN/BYZhJ1TsS6Hu7A0FTwqbw/yPXBo=; b=Q2isDQgzQ0CJOTO14B0/f2vUq37/MpwXOtsVK7gtYzF+HlVWWtUtA7oegN8bMObbio gI/asxi08BOHvNTT8QDUToLC0axVqRlo7fJXWzhTZ5T8H7cRSEkrndOtUa2l0qWI3bcd hcS2hm2MiBN6q7yjijogBomssVjuunEUXXQS86CuvpjauKU465c8mkxARGBIt75JGP/Q RKrmEUptjpLDHOyAz66X6gE8UMLnwsQyHRY0Vpj5MMUC1cqYDfcH119wY1GpcqgUWSiR lJhhKZoz9V9/U1sMBLTd/XS32yk+wA/wP7yZdh7WHsFCRhnQG8pboH1G44obRHe73d3U DsIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715310556; x=1715915356; h=mime-version:user-agent:message-id:date:subject:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Njm5K/OzxKfcDwN/BYZhJ1TsS6Hu7A0FTwqbw/yPXBo=; b=AHWIXgHnooTPsDUfxD2DjMqB5iAFR6aqbKy9tsPm6o6WjRm0TQKOHWJUbRHT14rfIT MxgzcSakfAiF1BwyTD/fcI21eBiQsEhDZWmeQ9rfzb+i5DprI+0Df+OM7Fpg3Amsvd1M AvbzfpwMLITyiKQTY5rPgEe3FbjrgEVj+D7Ni1wYomBsbmFA50+2UV4lESNcNXltFj7G aJifBkgN2nHY8IPv1ym+vxAjRuMt2J0tU86CxNLB8aEtPAsKtyeIajsLe1/3u/1Vcw0F jUddUCpnlKxUcEkOh3N90SzprzASr7sS0Pgz3KqpgrGdzPNomZArmJngh86qsd/f/6zk Qctg== X-Gm-Message-State: AOJu0YzckgAbE5IyRDWrKdQTJ9sX/KjY9e7i+QDUrd2dV/ibeVYOQWq/ c9cw4pvXxtmZO5M9nJHcBK4pC2KjZEDqbX0GMoh9SVhoVQicrh8M5SS0xQ== X-Google-Smtp-Source: AGHT+IFt4Hs4BFymqj3QJWGrR5DTeHHrbEejjlft9Yxy9QheM04iygF1goV9+tef2o27RtSSzIUwfg== X-Received: by 2002:a17:902:cf10:b0:1e2:ae83:3197 with SMTP id d9443c01a7336-1ef43d155a4mr18728305ad.10.1715310556069; Thu, 09 May 2024 20:09:16 -0700 (PDT) Original-Received: from debian-hx90 ([2603:8000:a400:cdc:e91:a1eb:9ad7:8e76]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1ef0bad84f4sm21683315ad.91.2024.05.09.20.09.15 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 May 2024 20:09:15 -0700 (PDT) Received-SPF: pass client-ip=2607:f8b0:4864:20::62e; envelope-from=manphiz@gmail.com; helo=mail-pl1-x62e.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:319104 Archived-At: (I'm not sure whether this is the right mailing list for this kind of question. Please help redirect if possible.) Hi, I would like to understand how package.el handles `load-path' of installed ELPA packages. As I observe from load-path after ELPA packages are initialized, it looks like only the package installation root path is added to `load-path', but not any of the nested directory. For example, if an addon `elpafoo` has a nested `elpabar' directory, as in the following example: ,---- | ~/.config/emacs/elpa/elpafoo/ | ~/.config/emacs/elpa/elpafoo/elpafoo.el | ~/.config/emacs/elpa/elpafoo/elpabar | ~/.config/emacs/elpa/elpafoo/elpabar/elpabar.el `---- For such a package, both `elpafoo.el' and `elpabar/elpabar.el' will be byte-compiled, but only `~/.config/emacs/elpa/elpafoo' is added to `load-path', not `~/.config/emacs/elpa/elpafoo/elpabar'. I was trying to find in package.el source where this is handled but cannot seem to have a definite answer. So I wonder whether my current understanding is correct? Is this going to be the case forward? And if possible which code path is handling this logic? To give a little more background (probably long), I was studying dh-elpa which is Debian's tool that handles Emacs addons in a similar fashion as how ELPA packages are handled, which among other things handles the byte compiling of the source files to generate *.elc files. Up to now, dh-elpa doesn't support nested directories, so if an addon has *.el in a nest directory they won't be byte-compiled. This has been working well up-to-now, but I noticed that some ELPA packages (e.g. auctex) have nested directories and handled like I mentioned above, which dh-elpa ignores. I tried to add nested directory handling, which handles the package installation under `/usr/share/emacs/site-lisp/elpa' and somehow all nested directories are added to `load-path' as well (it's adding this directory to package-directory-list but I'm not sure whether this is the reason of the nested directories being added to `load-path'). Normally this should not be a problem, but for the case of auctex, it has some source files under `style/' named `url.el', `array.el', etc., which collide with system packages and they don't have any `(provide 'foo)' declared in the source files. So in my Emacs installation, in which I use eglot-ensure in all prog-mode, eglot was broken as it tries to load those alternative url.el, array.el and so on instead of the ones shipped in Emacs, and as they don't have the corresponding `provide', it causes error and Emacs will stop processing further. Sorry this is getting a lot longer that it was supposed to be. So in the end I have the following questions: * For ELPA package installed through package.el, should only the installation root path be added to `load-path'? - Or recursively add nested directories will also be considered in the future? * If it happens to be the latter case, is there any guidelines for packages to avoid potential name collision? * Would someone kindly provide some pointer to how `load-path' is being handled as my rusty Elisp is preventing me to fully understand this. Thanks for reading this unexpectedly (maybe unnecessarily) long post, and looking forward to any insights. -- Xiyue Deng