From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 2OaoKb2z4V9YGQAA0tVLHw (envelope-from ) for ; Tue, 22 Dec 2020 08:52:13 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id SORxJb2z4V/MRQAAB5/wlQ (envelope-from ) for ; Tue, 22 Dec 2020 08:52:13 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id AA1CD9404C9 for ; Tue, 22 Dec 2020 08:52:12 +0000 (UTC) Received: from localhost ([::1]:38438 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1krdOs-0004Ni-Na for larch@yhetil.org; Tue, 22 Dec 2020 03:52:10 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:44888) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1krdOk-0004NZ-FC for bug-guix@gnu.org; Tue, 22 Dec 2020 03:52:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:37361) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1krdOk-0000oL-85 for bug-guix@gnu.org; Tue, 22 Dec 2020 03:52:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1krdOk-00026k-7G for bug-guix@gnu.org; Tue, 22 Dec 2020 03:52:02 -0500 X-Loop: help-debbugs@gnu.org Subject: bug#45316: [PATCH]: Re-introduce Emacs packages specific installation prefix. Resent-From: Leo Prikler Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Tue, 22 Dec 2020 08:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45316 X-GNU-PR-Package: guix X-GNU-PR-Keywords: patch To: Maxim Cournoyer Received: via spool by 45316-submit@debbugs.gnu.org id=B45316.16086271208094 (code B ref 45316); Tue, 22 Dec 2020 08:52:02 +0000 Received: (at 45316) by debbugs.gnu.org; 22 Dec 2020 08:52:00 +0000 Received: from localhost ([127.0.0.1]:48907 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1krdOh-00026R-CR for submit@debbugs.gnu.org; Tue, 22 Dec 2020 03:51:59 -0500 Received: from mailrelay.tugraz.at ([129.27.2.202]:21691) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1krdOe-00026F-Vr for 45316@debbugs.gnu.org; Tue, 22 Dec 2020 03:51:59 -0500 Received: from nijino.local (217-149-174-13.nat.highway.telekom.at [217.149.174.13]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4D0VSm4dcBz1LBMy; Tue, 22 Dec 2020 09:51:52 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4D0VSm4dcBz1LBMy DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1608627112; bh=mbppzh1vJx+5OxHjZFrhb48nTJWKQGHSt+PGNbQkyEo=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=IYplVxRi1QKofYCrYs+gh0kgySwTUp8oy9ekxRIXgPWfturqXC6AmIxe2M0cYplpb D87SaMWLyG/5HB+8tgcmHyJJUhugI7Wy8dJwN7KajxZMLoEDfkBeQc6u2u/cKMvk0n +w4XuC11Vc0U5Eifxs5tNH9LjGNJAO5G7dJROL+s= Message-ID: <878dbbdf4883d509865a1049c11fbe9ae792cace.camel@student.tugraz.at> From: Leo Prikler Date: Tue, 22 Dec 2020 09:51:51 +0100 In-Reply-To: <87ft3ysen7.fsf@gmail.com> References: <87ft3ysen7.fsf@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: 45316@debbugs.gnu.org Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -1.22 Authentication-Results: aspmx1.migadu.com; dkim=fail (headers rsa verify failed) header.d=tugraz.at header.s=mailrelay header.b=IYplVxRi; dmarc=fail reason="SPF not aligned (relaxed)" header.from=student.tugraz.at (policy=none); spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Queue-Id: AA1CD9404C9 X-Spam-Score: -1.22 X-Migadu-Scanner: scn0.migadu.com X-TUID: In5CNroaMgbN Hello Maxim, As someone, who lobbied for the current status quo, I have some thoughts to share. Am Montag, den 21.12.2020, 22:28 -0500 schrieb Maxim Cournoyer: > The Emacs packages built with the Emacs built system used to be > installed in a sub-directory under the share/emacs/guix.d/ directory, > but this was changed in commit > 65a7dd2950ca13a8b942b2836260a2192351b271 > shortly after having accommodated the site-start.el machinery to > enable > loading packages from any profile (via the EMACSLOADPATH search path > specification). Won't this reintroduce then? > While this change allowed to expose simply and directly the packages > found in EMACSLOADPATH, it does introduce the risk of file name > collisions when multiple Emacs packages are joined in the same > profile, > especially with Emacs packages increasing in complexity (e.g., using > more than a single .el file!) and expecting to have both their > sources > and resources extracted under their own nested directory rather than > as > a flat collection (ELPA, MELPA). > One recent example I stumbled on was attempting to use the > emacs-yasnippet-snippets package along with emacs-elpy; both wanted > to > install a 'snippets' directory to share/emacs/site-lisp/snippets, > collided and resulted in problems that prove difficult to understand. I believe that to be a problem in those packages. Data should not be installed into share/emacs/site-lisp, but share/emacs/etc. See for instance also emacs-telega, which – while not quite adhering to the above – installs its data in share/emacs/{telega-contrib,telega-data}. Regardless of what you intend to do with site-lisp otherwise, data files should *not*, I repeat *not* be installed there. I do believe standardizing share/emacs/etc is the way to go, however. > This is what motivated this patch series, where the site-start.el > auxiliary code used for package discovery is extended to support > packages installed in their own directory under a 'share/emacs/guix' > installation prefix, via Emacs' own package library! > > The emacs-build-system is updated for this new installation prefix, > as > well as existing packages and documentation. Parting with a directly > usable EMACSLOADPATH means that site-start.el *must* run for packages > to > appear in the load-path; that means for running a test suite, the -Q > or > --quick Emacs options cannot be used, since it implies --no-site- > file. Having no usable EMACSLOADPATH sounds like a dealbreaker to me. Could one be restored by using direct subdirectories to share/emacs/site-lisp or would that merely be a cosmetic change? > + Avoid inter-package file name collisions. Note: This regards data, which should not be stored in site-lisp to begin with. You don't get any benefits doing this for code, because Emacs has no strong module system. > + Better integration with user installed packages via M-x > package-install. The Guix-installed packages are listed in M-x > package-list as 'external'. That does sounds like a genuine pro to me. > - Slightly more complex loader (although much of it is offloaded to > package.el), thus slightly slower (see the comparison below). That should be bearable. > - Requires to ensure every package's test suite doesn't make use of > -Q. That not so much. Note, that test cases are not the only use for -Q! > In my opinion the benefits outweighs the cons by a comfortable > margin, > especially with the boring work of adapting the package collection > already done. > > To test the performance of the new approach, the following manifest > file > was used to test the rebuild of the ~900 Emacs packages making use of > the Emacs build system: > > A simple benchmark testing the performance of the activation of the > hundreds of Emacs packages was then run using: > > --8<---------------cut here---------------start------------->8--- > $ ./pre-inst-env guix environment --pure -m emacs-packages- > manifest.scm \ > --ad-hoc emacs > [env]$ /run/setuid-programs/sudo /bin/sh -c 'echo 3 > > /proc/sys/vm/drop_caches' > [env]$ emacs --batch --no-site-file \ > --eval="(progn (require 'guix-emacs) \ > (require 'benchmark) \ > (message \"(total gc-count gc-time) = %s\" \ > (benchmark-run 1 (guix-emacs-autoload- > packages))))" > --8<---------------cut here---------------end--------------->8--- > > On the master branch: > > --8<---------------cut here---------------start------------->8--- > [...] > Loading /gnu/store/qajc70c7nqycs1301ram8s3x7k9ibg5f- > profile/share/emacs/site-lisp/zotxt-autoloads... > Loading /gnu/store/qajc70c7nqycs1301ram8s3x7k9ibg5f- > profile/share/emacs/site-lisp/zoutline-autoloads... > Loading /gnu/store/qajc70c7nqycs1301ram8s3x7k9ibg5f- > profile/share/emacs/site-lisp/ztree-autoloads... > (total gc-count gc-time) = (25.242400751 13 0.189669369) > --8<---------------cut here---------------end--------------->8--- > > Or about 0.65 s on a warm cache. > > On a branch with these changes: > > --8<---------------cut here---------------start------------->8--- > Error loading autoloads: (file-missing Cannot open load file No such > file or directory kotl/kotl-autoloads) > Error loading autoloads: (file-missing Cannot open load file No such > file or directory helm-easymenu) > Error loading autoloads: (file-missing Cannot open load file No such > file or directory /gnu/store/ryh0rasi9frm98dkd3kbck6hya6hn2qr- > profile/share/emacs/site-lisp/guix/flycheck-cpplint-0.1- > 1.1d8a090/flycheck-cpplint-autoloads) > Error loading autoloads: (file-missing Cannot open load file No such > file or directory /gnu/store/ryh0rasi9frm98dkd3kbck6hya6hn2qr- > profile/share/emacs/site-lisp/guix/evil-anzu-0.03/evil-anzu- > autoloads) > Error loading autoloads: (file-missing Cannot open load file No such > file or directory /gnu/store/ryh0rasi9frm98dkd3kbck6hya6hn2qr- > profile/share/emacs/site-lisp/guix/erc-image-0-3.82fb387/erc-image- > autoloads) > ad-handle-definition: `ido-completing-read' got redefined > Error loading autoloads: (file-missing Cannot open load file No such > file or directory tex-site) > (total gc-count gc-time) = (26.175704339 47 0.783184412) > --8<---------------cut here---------------end--------------->8--- > > Or about 3 seconds on a warm cache. Looking at these, total does not seem to have changed much, but gc- count and gc-time more than tripled. Any idea on how to mitigate this or do we have to live with that? > There a 6 errors that would need to be looked into, but I these look > like actual packaging problems rather than new issues. The > previously > used way to load the autoloads, '(load f 'noerror)' would have masked > them. Regardless of how we handle site-lisp going forward, please do look into those issues and perhaps file them against the individual packages if they also cause (other) trouble using the current setup. Regards, Leo