From unknown Sun Jun 22 00:39:35 2025 X-Loop: help-debbugs@gnu.org Subject: bug#67696: 30.0.50; Help deal with multiple versions in load-path Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: monnier@iro.umontreal.ca, bug-gnu-emacs@gnu.org Resent-Date: Thu, 07 Dec 2023 16:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 67696 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 67696@debbugs.gnu.org Cc: monnier@iro.umontreal.ca X-Debbugs-Original-To: bug-gnu-emacs@gnu.org X-Debbugs-Original-Xcc: monnier@iro.umontreal.ca Received: via spool by submit@debbugs.gnu.org id=B.170196737121859 (code B ref -1); Thu, 07 Dec 2023 16:43:02 +0000 Received: (at submit) by debbugs.gnu.org; 7 Dec 2023 16:42:51 +0000 Received: from localhost ([127.0.0.1]:42872 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBHSc-0005gU-L9 for submit@debbugs.gnu.org; Thu, 07 Dec 2023 11:42:51 -0500 Received: from lists.gnu.org ([2001:470:142::17]:48468) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBHSb-0005gE-8A for submit@debbugs.gnu.org; Thu, 07 Dec 2023 11:42:50 -0500 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 1rBHSD-00051n-HP for bug-gnu-emacs@gnu.org; Thu, 07 Dec 2023 11:42:27 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rBHSB-0006rL-3c for bug-gnu-emacs@gnu.org; Thu, 07 Dec 2023 11:42:25 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 39E16443043 for ; Thu, 7 Dec 2023 11:42:21 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1701967339; bh=4ncMWEuiPUhtHWBDDwgrBn7lQWguI1SGF6EFG5yBHj8=; h=From:To:Subject:Date:From; b=Vn7+2193tA5DOpBQMq7+64MhZbXJtM4iIn9NKDQciHe4WilYwwasbeW7QqW3AoEXn iYXWFMCIbMdMMjeq1caa2FD/O9dHTXu5oiyBPCPsPQXg4tPZjKHns/5dm5sECfESM0 AcnZm6TcU2QTgTQzEp0hqnW3ze6814EK5ZWdbMzfsxM/+I66zW62GsBBa2smOd/RcO WESLzg5rB0QudlMQXagwF7hmfSPWO3ObBtIWGWzVKtwXXd3Dv5abrT1OUYcifGV9JI 6hEue9Y2pOdiNEndCtsePY6Yd0sQf2eXXJ5Ty734Kx0aU82d5uieCpTu9JKwm6lGxc 7v6Ol9qwMB++g== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 97DD9442FF9 for ; Thu, 7 Dec 2023 11:42:19 -0500 (EST) Received: from pastel (unknown [45.72.194.97]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 704F0120301 for ; Thu, 7 Dec 2023 11:42:19 -0500 (EST) From: Stefan Monnier Date: Thu, 07 Dec 2023 11:42:12 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.025 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Package: Emacs Version: 30.0.50 With packages being available both as bundled with Emacs and as ELPA packages, it has become a lot more common place to have two versions of a package in the `load-path` and to have to deal with situations where the "incorrect" version has been loaded before `load-path` was changed. These kinds of problems manifest in various ways and we try to circumvent them in `package.el` in some cases but that can't cover all cases. I suggest we introduce a new function to help packages susceptible to those problems. The patch below introduces a new function which I tentatively called `require-with-check` and shows how it could be used in the case of `eglot.el` (which relies on several core packages also distributed via GNU ELPA and currently uses a hack which slows it down unnecessarily in the normal case). As mentioned in a FIXME in there, maybe we should also consider adding to `seq` (and `eldoc`) something like ;;;###autoload (if (featurep 'seq) (require-with-check 'seq 'reload)) -- Stefan --=-=-= Content-Type: text/x-diff; charset=utf-8 Content-Disposition: inline; filename=require-with-check.patch Content-Transfer-Encoding: quoted-printable diff --git a/lisp/files.el b/lisp/files.el index 1cdcec23b11..e1e885462ce 100644 --- a/lisp/files.el +++ b/lisp/files.el @@ -1246,6 +1246,29 @@ load-library (interactive (list (read-library-name))) (load library)) =20 +(defun require-with-check (feature &optional filename noerror) + "If FEATURE is not already loaded, load it from FILENAME. +This is like `require' except if FEATURE is already a member of the list +`features=E2=80=99, then we check if this was provided by a different file= than the +one that we would load now (presumably because `load-path' has been +changed since the file was loaded). +If it's the case, we either signal an error (the default), or forcibly rel= oad +the new file (if NOERROR is equal to `reload'), or otherwise emit a warnin= g." + (let ((lh load-history) + (res (require feature filename (if (eq noerror 'reload) nil noerro= r)))) + ;; If the `feature' was not yet provided, `require' just loaded the ri= ght + ;; file, so we're done. + (when (eq lh load-history) + ;; If `require' did nothing, we need to make sure that was warranted. + (let ((fn (locate-file (or filename (symbol-name feature)) + load-path (get-load-suffixes)))) + (cond + ((assoc fn load-history) nil) ;We loaded the right file. + ((eq noerror 'reload) (load fn nil 'nomessage)) + (t (funcall (if noerror #'warn #'error) + "Feature provided by other file: %S" feature))))) + res)) + (defun file-remote-p (file &optional identification connected) "Test whether FILE specifies a location on a remote system. A file is considered remote if accessing it is likely to diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el index d410367f902..8124a3f52e0 100644 --- a/lisp/progmodes/eglot.el +++ b/lisp/progmodes/eglot.el @@ -116,13 +116,16 @@ ;; having installed them, didn't correctly re-load them over the ;; built-in versions. (eval-and-compile - (load "project") - (load "eldoc") - (load "seq") - (load "flymake") - (load "xref") - (load "jsonrpc") - (load "external-completion")) + ;; For those packages that are preloaded, reload them if needed, + ;; since that's the best we can do anyway. + ;; FIXME: Maybe the ELPA packages for those preloaded packages should + ;; force-reload themselves eagerly when the package is activated! + (require-with-check 'eldoc nil 'reload) + (require-with-check 'seq nil 'reload) + ;; For those packages which are not preloaded OTOH, signal an error if + ;; the loaded file is not the one that should have been loaded. + (mapc #'require-with-check + '(project flymake xref jsonrpc external-completion))) =20 ;; forward-declare, but don't require (Emacs 28 doesn't seem to care) (defvar markdown-fontify-code-blocks-natively) @@ -138,11 +141,12 @@ tramp-use-ssh-controlmaster-options 'eglot-managed-mode-hook "1.6") (define-obsolete-variable-alias 'eglot-confirm-server-initiated-edits 'eglot-confirm-server-edits "1.16") -(define-obsolete-function-alias 'eglot--uri-to-path 'eglot-uri-to-path "1.= 16") -(define-obsolete-function-alias 'eglot--path-to-uri 'eglot-path-to-uri "1.= 16") -(define-obsolete-function-alias 'eglot--range-region 'eglot-range-region "= 1.16") -(define-obsolete-function-alias 'eglot--server-capable 'eglot-server-capab= le "1.16") -(define-obsolete-function-alias 'eglot--server-capable-or-lose 'eglot-serv= er-capable-or-lose "1.16") +(define-obsolete-function-alias 'eglot--uri-to-path #'eglot-uri-to-path "1= .16") +(define-obsolete-function-alias 'eglot--path-to-uri #'eglot-path-to-uri "1= .16") +(define-obsolete-function-alias 'eglot--range-region #'eglot-range-region = "1.16") +(define-obsolete-function-alias 'eglot--server-capable #'eglot-server-capa= ble "1.16") +(define-obsolete-function-alias 'eglot--server-capable-or-lose + #'eglot-server-capable-or-lose "1.16") (define-obsolete-function-alias 'eglot-lsp-abiding-column 'eglot-utf-16-linepos "1.12") (define-obsolete-function-alias --=-=-=-- From unknown Sun Jun 22 00:39:35 2025 X-Loop: help-debbugs@gnu.org Subject: bug#67696: 30.0.50; Help deal with multiple versions in load-path Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Dec 2023 19:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67696 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 67696@debbugs.gnu.org Cc: monnier@iro.umontreal.ca Received: via spool by 67696-submit@debbugs.gnu.org id=B67696.170275365428621 (code B ref 67696); Sat, 16 Dec 2023 19:08:01 +0000 Received: (at 67696) by debbugs.gnu.org; 16 Dec 2023 19:07:34 +0000 Received: from localhost ([127.0.0.1]:56038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rEa0c-0007RY-0O for submit@debbugs.gnu.org; Sat, 16 Dec 2023 14:07:34 -0500 Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]:60924) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rEa0Y-0007RI-MV for 67696@debbugs.gnu.org; Sat, 16 Dec 2023 14:07:32 -0500 Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-40c3f68b69aso17199545e9.1 for <67696@debbugs.gnu.org>; Sat, 16 Dec 2023 11:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702753644; x=1703358444; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=mB+n8rvPKkIgZAN5qmpllNh43brUCAxWOzClDmPgNTA=; b=KhU6I2FlmaeLs8HKjeeEjPbfkJukr/F0RqcT4me19wR6RNuuhB/IIu/2TpfyQ/zk8S 4fi9cDrUsi6z7atfnml3ACSdK33VOrbDK0AWjixPUdxy/3ew0IFDC+JJ6vh5BkCY6iUf lJKBQwwj5wnPIs6169KT4E4NqfYN+nIFhZ9fM2FDPLxEb+YRGdhp4FXJTd/ZIBHjdHIH LagUNgA8KPaOW+hMLkJkZHptUJckJ2vioN51itSv5vMC/p2bJYcufQnhiGm/zrC4HDd9 0svoV46gpQmwh73p9I91juwkS4WPGx+DAQjlHLO/F1VRRJc5et0lbK6TjHiv+Skrsjve 3Mxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702753644; x=1703358444; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mB+n8rvPKkIgZAN5qmpllNh43brUCAxWOzClDmPgNTA=; b=NQP8Tj0Ai6ZTmDlgvONK+eLVGVt0u2bv8/8Krm1pm6TmsJ7J3rCwZ9uQZxBUXMGy/0 JsKlAkRnPHXoxv8w+f/mTDtLrKLbUfTNzsbOMLcdcw76Y3VjnqaaGvMbQAvu2w333nht SSPwzE1CgCe/Q2WqYx45G0aEvpMmJVM9WlTp6bogZ+lN6qgSGA5peIgQYCiqfIFTWuUY Daucb1fCyiWxuWBdTPGiFOwqOGKRupJwKSfcqSedMG54GPYgMvXqWvKDGMMautal2+Fk vjq9JoLjBQMIWLU57ADi3bJfMcA9+1uRha2d4VWNvoZLSmYRkqPYQYINQtcPXnrlxJ28 CLgw== X-Gm-Message-State: AOJu0YyndW93o83nK/Na5jizYAISb7UgK19yRH2CFWFesmTj9KX+bs5h erriechyobJFAwyJt5EYk07Kbhgmr7F2DmrGmZ+dMzJSJYZIuQ== X-Google-Smtp-Source: AGHT+IFQl0u7eJhIvxEoawAbJW1HyI2/7F+12vIx9gFufN8DhMUxXcD5hkNT7MKmRE8jGgKulLUoXnkrRC3eNeSDGTc= X-Received: by 2002:a5d:52cd:0:b0:336:9ec:68d with SMTP id r13-20020a5d52cd000000b0033609ec068dmr7196477wrv.9.1702753643753; Sat, 16 Dec 2023 11:07:23 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sat, 16 Dec 2023 11:07:23 -0800 From: Stefan Kangas In-Reply-To: References: MIME-Version: 1.0 Date: Sat, 16 Dec 2023 11:07:23 -0800 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > With packages being available both as bundled with Emacs and as ELPA > packages, it has become a lot more common place to have two versions of > a package in the `load-path` and to have to deal with situations > where the "incorrect" version has been loaded before `load-path` > was changed. > > These kinds of problems manifest in various ways and we try to > circumvent them in `package.el` in some cases but that can't cover > all cases. > > I suggest we introduce a new function to help packages susceptible to > those problems. The patch below introduces a new function which > I tentatively called `require-with-check` and shows how it could be used > in the case of `eglot.el` (which relies on several core packages also > distributed via GNU ELPA and currently uses a hack which slows it down > unnecessarily in the normal case). Will this be useful only for :core packages? If so, it would be nice to not have to introduce more functions and extra complexity just to deal with this situation. It seems like a problem we should be able to fix without it leaking into our API. I didn't think deeply about this so here's a probably naive question: could we make `require' reload the file, if a newer one is detected earlier in the load-path? Are there any other alternative approaches that you considered? From unknown Sun Jun 22 00:39:35 2025 X-Loop: help-debbugs@gnu.org Subject: bug#67696: 30.0.50; Help deal with multiple versions in load-path Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Dec 2023 19:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67696 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Kangas Cc: 67696@debbugs.gnu.org Received: via spool by 67696-submit@debbugs.gnu.org id=B67696.170275624830493 (code B ref 67696); Sat, 16 Dec 2023 19:51:01 +0000 Received: (at 67696) by debbugs.gnu.org; 16 Dec 2023 19:50:48 +0000 Received: from localhost ([127.0.0.1]:56102 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rEagR-0007vl-Us for submit@debbugs.gnu.org; Sat, 16 Dec 2023 14:50:48 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:4532) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rEagO-0007vT-8Z for 67696@debbugs.gnu.org; Sat, 16 Dec 2023 14:50:46 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A48E5441E2A; Sat, 16 Dec 2023 14:50:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1702756236; bh=tnl/Hm6zOsCqBo26wK7YlkB4TVeC22x/iqZu6OdDSAU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=UFdFXDnqcajy6QHZN5mx+BZJgXkNktGxVSbGJjLJFGoeeFPl1G02RBKL0BV8biumj M81mwlG8cfqaE7KQjK9AOAWL3Q98JP2yHoDhTbDT8PXl66H5prBBKvvSogyjhoL2FL 93bcCG9eMXB3fXpeRWBpzLzr7AGGdlLeWXQFIWOPhTfJtEdihjpFH0P13R1+OQ+eLf dq9kVk+6hR6teNcXCWdYHI+qYRWw/EscsKilJP/bpgosE9mGlVut0g/9MhIZwzN9IV IaVCPTLaPSLb8ZUr4KdxfYHJCj/IkK7Bu2cH0HYCnNGsfxpNcXKdSo41uRJjuqFoNF MAvbvBKQIt34g== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 1056B441E27; Sat, 16 Dec 2023 14:50:36 -0500 (EST) Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E27AE1206E8; Sat, 16 Dec 2023 14:50:35 -0500 (EST) From: Stefan Monnier In-Reply-To: (Stefan Kangas's message of "Sat, 16 Dec 2023 11:07:23 -0800") Message-ID: References: Date: Sat, 16 Dec 2023 14:50:34 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.044 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> With packages being available both as bundled with Emacs and as ELPA >> packages, it has become a lot more common place to have two versions of >> a package in the `load-path` and to have to deal with situations >> where the "incorrect" version has been loaded before `load-path` >> was changed. >> >> These kinds of problems manifest in various ways and we try to >> circumvent them in `package.el` in some cases but that can't cover >> all cases. >> >> I suggest we introduce a new function to help packages susceptible to >> those problems. The patch below introduces a new function which >> I tentatively called `require-with-check` and shows how it could be used >> in the case of `eglot.el` (which relies on several core packages also >> distributed via GNU ELPA and currently uses a hack which slows it down >> unnecessarily in the normal case). > Will this be useful only for :core packages? AFAIK it's useful only to detect and/or work around problems linked to interleavings of loading files and changing `load-path`. I can't think of any reason why this would be limited to :core packages, but it's a problem that shows up more commonly for :core packages, indeed. > If so, it would be nice to not have to introduce more functions and > extra complexity just to deal with this situation. It seems like > a problem we should be able to fix without it leaking into our API. Another option is to tweak `require` directly: the new function works basically "identically" to `require` expect for the added checks. > I didn't think deeply about this so here's a probably naive question: > could we make `require' reload the file, if a newer one is detected > earlier in the load-path? By default I made the function signal an error rather than reload, because reloading is not a really reliable solution (`defvar` won't be updated to the new value, renamed functions will linger, ...). But yes, we could change `require` to behave more like `require-with-check`. The downside is that it's more risky, and it may come with a performance cost (it means that calling `require` repeatedly isn't as cheap as `(memq F features)`). > Are there any other alternative approaches that you considered? Many other approaches have been mentioned/considered in the long discussion around Org mode's attempt to deal with similar problems. I found this one approach to be the clea[rn]est because it seemed to get to the actual core of the problem and deals with a known problem (file shadowing) that's reasonably easy&cheap to check reliably at runtime. As you can see in my patch, Eglot took the other approach to blindly reload the files (which kind of works but is less efficient and suffers from further subtle differences with `require` such as the presence of a load message, or the absence of an entry in `load-history`). Org took yet another approach (signal an error if the loaded version is different from the file's own notion of version), but it suffers from annoying false positives and requires more ad-hoc support (it relies on having a version, on hard-coding that version info in the .elc files, and on someone manually updating that version info when needed), so it's harder to turn it into a generic solution. Stefan From unknown Sun Jun 22 00:39:35 2025 X-Loop: help-debbugs@gnu.org Subject: bug#67696: 30.0.50; Help deal with multiple versions in load-path Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Dec 2023 17:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67696 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 67696@debbugs.gnu.org Received: via spool by 67696-submit@debbugs.gnu.org id=B67696.170283371027122 (code B ref 67696); Sun, 17 Dec 2023 17:22:01 +0000 Received: (at 67696) by debbugs.gnu.org; 17 Dec 2023 17:21:50 +0000 Received: from localhost ([127.0.0.1]:58983 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rEupq-00073O-21 for submit@debbugs.gnu.org; Sun, 17 Dec 2023 12:21:50 -0500 Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]:55477) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rEupo-00073A-1L for 67696@debbugs.gnu.org; Sun, 17 Dec 2023 12:21:48 -0500 Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-54cd2281ccbso2553142a12.2 for <67696@debbugs.gnu.org>; Sun, 17 Dec 2023 09:21:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702833701; x=1703438501; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=rm0ZP77zJLXnfec5dP3rxyAj0yxpOr4RX09mV6h1NPk=; b=gz0fvDN+WKGpLnkdPX8CqvkO3Fysf2HyVIzZ4RAiyqwBGLOboghBDLYoBlWDVsSly4 EdgHrXTfYj2GRz6ufrEfeJda8HU88XpTKF0rUpnFB3Zs6Nbj3ZywUpJ4tauMo8jtsxmq VxtadGcz7iM1HG07ccsTw2CtEyL0IxtkxyUmRxexnENln1jJ3E9DwJJCr79OZCpMc5H8 FUbDLVEgJh2LXIBzHTlH0Wk/dVDLCvZ+/I2qYndzUdzpymFzHZR+S2JcOLWHgCLKsXtd ssQKw25LLHXFPkcX9sFvoXbb7nTc/mtm8sgbxX0T+UHwGitN720oTKFAELErhBAMsHfy I0uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702833701; x=1703438501; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rm0ZP77zJLXnfec5dP3rxyAj0yxpOr4RX09mV6h1NPk=; b=Mv+Tm5/3WfIeSME9kmM/eFPOZ37wvTtQE4sHhoYl3UpzexXF9ZpkNcN4yUAU6Fh5Vy ojNEPOXz8NGSTTOMlVzdJ8xHqD/Gt2Q7L/jZvZv1x0MftsTB+/Lly/Stv0zglc2atY9x ZtzhAzrKgwhrXaBxCreqzE4LbjPBo5CtDkFqMHIhRu87QEVmcvdnYArznEFjZeJWHK8B YBJQFUK768ZXfbfRafQiRWMhe66rHLTghcoCzXG65WkoYOHu1UKWeq/c3yyTGWsO2vjb h2a6f5zCcc/aStJh//lPVVMzihuS5OKboAroaXV4sU2tnH1p/XhRKrD+z82tD4ITDaOu fTvA== X-Gm-Message-State: AOJu0YxTIJQArTq2qXuYhe0u6mwuOnXN1QynnQA2p2tpH0nGNhkBjrqS G1/2cNXbqiTan1fcfFThE0adUDGTPCmXanIfnY4= X-Google-Smtp-Source: AGHT+IGRnNrSLihqT6tPsmquGZ31CUqBW8uExb3njptjJWNsAqgZ+NcQfI1zx51C+9IMY0yxfSNPEnFNU/dOYM96CYo= X-Received: by 2002:a50:b411:0:b0:553:43e3:df2e with SMTP id b17-20020a50b411000000b0055343e3df2emr481235edh.60.1702833700519; Sun, 17 Dec 2023 09:21:40 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sun, 17 Dec 2023 09:21:39 -0800 From: Stefan Kangas In-Reply-To: References: MIME-Version: 1.0 Date: Sun, 17 Dec 2023 09:21:39 -0800 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: > Another option is to tweak `require` directly: the new function works > basically "identically" to `require` expect for the added checks. [...] > But yes, we could change `require` to behave more like > `require-with-check`. The downside is that it's more risky, and it may > come with a performance cost (it means that calling `require` repeatedly > isn't as cheap as `(memq F features)`). Right. On the other hand, perhaps hitting the file system is to some extent expected once you start asking for libraries to be loaded. You only get the best case `(memq F features)' if that evaluates to `t'. Personally, I don't have a good view of how common these problems are. Perhaps they are relatively uncommon, and it's too much to ask all users of `require' to pay a cost for added correctness in unusual cases. From unknown Sun Jun 22 00:39:35 2025 X-Loop: help-debbugs@gnu.org Subject: bug#67696: 30.0.50; Help deal with multiple versions in load-path Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Dec 2023 23:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67696 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Kangas Cc: 67696@debbugs.gnu.org Received: via spool by 67696-submit@debbugs.gnu.org id=B67696.17028543962726 (code B ref 67696); Sun, 17 Dec 2023 23:07:02 +0000 Received: (at 67696) by debbugs.gnu.org; 17 Dec 2023 23:06:36 +0000 Received: from localhost ([127.0.0.1]:59148 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rF0DT-0000hu-Jh for submit@debbugs.gnu.org; Sun, 17 Dec 2023 18:06:35 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:27870) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rF0DR-0000hg-QO for 67696@debbugs.gnu.org; Sun, 17 Dec 2023 18:06:34 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7DADE10009E; Sun, 17 Dec 2023 18:06:26 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1702854385; bh=vTAz5waY0sVz+i9+h/VL9752Y25BrKixM01ek1DAURs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=OA3tbeAhXOSpczaMR9hf4xqNwERqBOQjCi1Ipktv6a+vsLmT0wwzKtcDm+/pdvVZc 7mMIJuIhLDrdp706F/DkPygu9kMZV10e6ue3myH45V9idPx36d2IX/sjgJMQkoY1K6 Am672dQ6D0+nPMcEnyCF44FEBaRGSqUFbbmPH6aIGojvPWiLbM4BAbml5rvNoxU//C ZUmwHKLwbR9dpOqk2F/HbRoICWhKWhEuGvrFUtepZXS2rNqXncDEZu9HAA0Kpswu9L S2fUviTjX3H1/gWS5YhCan5ePjMiW5+RrEbQEF6GagaO/LZ3uOrDvDLtLyn1zr0w4D CwQG9NNXKqhqA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7A24410001D; Sun, 17 Dec 2023 18:06:25 -0500 (EST) Received: from alfajor (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5440A12023C; Sun, 17 Dec 2023 18:06:25 -0500 (EST) From: Stefan Monnier In-Reply-To: (Stefan Kangas's message of "Sun, 17 Dec 2023 09:21:39 -0800") Message-ID: References: Date: Sun, 17 Dec 2023 18:06:27 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.026 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Right. On the other hand, perhaps hitting the file system is to some > extent expected once you start asking for libraries to be loaded. You > only get the best case `(memq F features)' if that evaluates to `t'. For top-level uses of `require`, the performance impact is negligible. But for `require`s used within functions (basically performing manual autoloads), I'm worried that it could be problematic. > Personally, I don't have a good view of how common these problems are. > Perhaps they are relatively uncommon, and it's too much to ask all users > of `require' to pay a cost for added correctness in unusual cases. I don't either. That's why I preferred to define a new function, which lets us gain some experience with it. We may later opt to merge (some of) its functionality into `require`, of course. Stefan From unknown Sun Jun 22 00:39:35 2025 X-Loop: help-debbugs@gnu.org Subject: bug#67696: 30.0.50; Help deal with multiple versions in load-path Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 29 Dec 2023 14:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67696 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 67696@debbugs.gnu.org Received: via spool by 67696-submit@debbugs.gnu.org id=B67696.170385976724377 (code B ref 67696); Fri, 29 Dec 2023 14:23:02 +0000 Received: (at 67696) by debbugs.gnu.org; 29 Dec 2023 14:22:47 +0000 Received: from localhost ([127.0.0.1]:41069 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rJDl8-0006L7-Uq for submit@debbugs.gnu.org; Fri, 29 Dec 2023 09:22:47 -0500 Received: from mail-ed1-x531.google.com ([2a00:1450:4864:20::531]:42362) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rJDl5-0006Kr-Hg for 67696@debbugs.gnu.org; Fri, 29 Dec 2023 09:22:45 -0500 Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-5559df64497so2153272a12.1 for <67696@debbugs.gnu.org>; Fri, 29 Dec 2023 06:22:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703859757; x=1704464557; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=x0jODc8s3gDCE7ZEQrR9FAXHyEzap4eTTPPAV7b+WfA=; b=HckWlETk9jM0y8Q1Vnmg0eYXxzlSKPKTcrOIWfwVyWhH/8JiZh1ATSx5ics+Y0Cv6U NHzon7xIj/WbqLp28P8xijXLuMRb2pCckCD7sQrkIxd2CDtO3/yVX9G8Pb/7m/RKIEHk KSVmTVCvA3dgJrL2AeY3JM2GtTFlTI2lgEYA8DpWezVSGYIp37zzpfTrWwFP9jRApAwe 70wpYae7TXUfzI8CHqnqlUD9fYlKPhmyalOL4mSt+NqF9+vu9ksmHVqTrJYY8y0lKbqQ fyM/4J2xHMPI9o2Xp9zQ/5yANYieZP9tHLI60CRT46GcaoOMvjwcNngE9yPjy8gtcIhO itPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703859757; x=1704464557; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=x0jODc8s3gDCE7ZEQrR9FAXHyEzap4eTTPPAV7b+WfA=; b=UQNRqGAYWQje6lOeIo0oztCeI5AU7vXlxdahuONixs4LbY9l0I/qvAMMybFA+wadM9 Vm4EuPBUWM7DCIkUt+8DHpLiS3GakC4MG5Lh51PH2D3sKEKvdYbaNeMeZMV0AJCRWudi u+nLY8vfaRvO6pXOwRYihRurDhX4KTLHcEbr/mlWF5soy4PXMIs1uemVyhHfgFqC2RUN Ikp0jzXD2H94uPS4I7N9BoQ8lKKxMHM8XK3+sCsmzWXoMpxAs8cDAJwuKtGpLTvTUccZ q0BKHgbWt4aKqwswUc0cSRFcwGgRIUHTuUE4U4c8kestjw466QURgHAIkIkrF6nzs0Q6 YTEQ== X-Gm-Message-State: AOJu0Yy4UXR+MRV1AtTNKB700WuQokQsvY24YTPxCx/IgT/lNLJdB191 ZeCiZwY/Zinq2xPUj1YasCe/kMtCjriJLYJtIqqtb/TfJ8E= X-Google-Smtp-Source: AGHT+IHvg9cUwvUp/7bVNpPb2nydyCn6/fPM2EqJIhbdxwwtnquHkIJng+tmCg1zKR6YYppcYZg6ljaJslkSn4WXS3g= X-Received: by 2002:a50:c308:0:b0:555:d3f3:2089 with SMTP id a8-20020a50c308000000b00555d3f32089mr648846edb.35.1703859757382; Fri, 29 Dec 2023 06:22:37 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 29 Dec 2023 06:22:36 -0800 From: Stefan Kangas In-Reply-To: References: MIME-Version: 1.0 Date: Fri, 29 Dec 2023 06:22:36 -0800 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: >> Right. On the other hand, perhaps hitting the file system is to some >> extent expected once you start asking for libraries to be loaded. You >> only get the best case `(memq F features)' if that evaluates to `t'. > > For top-level uses of `require`, the performance impact is negligible. > But for `require`s used within functions (basically performing manual > autoloads), I'm worried that it could be problematic. > >> Personally, I don't have a good view of how common these problems are. >> Perhaps they are relatively uncommon, and it's too much to ask all users >> of `require' to pay a cost for added correctness in unusual cases. > > I don't either. That's why I preferred to define a new function, which > lets us gain some experience with it. We may later opt to merge (some > of) its functionality into `require`, of course. Makes sense to me, thanks. From unknown Sun Jun 22 00:39:35 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Stefan Monnier Subject: bug#67696: closed (Re: bug#67696: 30.0.50; Help deal with multiple versions in load-path) Message-ID: References: X-Gnu-PR-Message: they-closed 67696 X-Gnu-PR-Package: emacs Reply-To: 67696@debbugs.gnu.org Date: Fri, 29 Dec 2023 16:23:01 +0000 Content-Type: multipart/mixed; boundary="----------=_1703866981-20172-1" This is a multi-part message in MIME format... ------------=_1703866981-20172-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #67696: 30.0.50; Help deal with multiple versions in load-path which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 67696@debbugs.gnu.org. --=20 67696: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D67696 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1703866981-20172-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 67696-done) by debbugs.gnu.org; 29 Dec 2023 16:22:37 +0000 Received: from localhost ([127.0.0.1]:42081 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rJFd6-0005Ek-Tm for submit@debbugs.gnu.org; Fri, 29 Dec 2023 11:22:37 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47069) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rJFd5-0005EU-EK for 67696-done@debbugs.gnu.org; Fri, 29 Dec 2023 11:22:36 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id BD16D838B7; Fri, 29 Dec 2023 11:22:29 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1703866948; bh=VsQpkGe9qPoqzVjTo+O82ZRYYtFs89loJzUX6qfb84Y=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nGvVlNdB8DIsqFpEa5TSnoA6p5L0v6K2HnzqHY+IRiPA/arKluaHr4ql/fJ7Ysone l1hUFgNCi1zVKv4HFHpvtp9RFYImXYdmDcWh4y3rKiVFq44Ju6WWbC8a1wGlFjyCP2 yw4VHV+xkFWhLClVktPhD8SQAkvImPFZX158iHqOl3Bviu/wcFutpjS3yFnuCCaZPj JJ2sldQAoEBJyhUa3teQJ+yLrNe7PfUS+BfFW7C3xg4ubeGdZKy8tRXEWYW8bYExvH CSYoYhLxS3g6Ye5fl9+VXXwyutkto6KUDlyddJK1K/joXYjBlJXUzcCl+QQaW5CM0c 5JEQI4pKZDtug== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E1E1A83257; Fri, 29 Dec 2023 11:22:28 -0500 (EST) Received: from alfajor (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C912E120CAA; Fri, 29 Dec 2023 11:22:28 -0500 (EST) From: Stefan Monnier To: Stefan Kangas Subject: Re: bug#67696: 30.0.50; Help deal with multiple versions in load-path In-Reply-To: (Stefan Kangas's message of "Fri, 29 Dec 2023 06:22:36 -0800") Message-ID: References: Date: Fri, 29 Dec 2023 11:22:28 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67696-done Cc: 67696-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Stefan Kangas [2023-12-29 06:22:36] wrote: > Makes sense to me, thanks. Thanks, pushed, closing, Stefan ------------=_1703866981-20172-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 7 Dec 2023 16:42:51 +0000 Received: from localhost ([127.0.0.1]:42872 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBHSc-0005gU-L9 for submit@debbugs.gnu.org; Thu, 07 Dec 2023 11:42:51 -0500 Received: from lists.gnu.org ([2001:470:142::17]:48468) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBHSb-0005gE-8A for submit@debbugs.gnu.org; Thu, 07 Dec 2023 11:42:50 -0500 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 1rBHSD-00051n-HP for bug-gnu-emacs@gnu.org; Thu, 07 Dec 2023 11:42:27 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rBHSB-0006rL-3c for bug-gnu-emacs@gnu.org; Thu, 07 Dec 2023 11:42:25 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 39E16443043 for ; Thu, 7 Dec 2023 11:42:21 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1701967339; bh=4ncMWEuiPUhtHWBDDwgrBn7lQWguI1SGF6EFG5yBHj8=; h=From:To:Subject:Date:From; b=Vn7+2193tA5DOpBQMq7+64MhZbXJtM4iIn9NKDQciHe4WilYwwasbeW7QqW3AoEXn iYXWFMCIbMdMMjeq1caa2FD/O9dHTXu5oiyBPCPsPQXg4tPZjKHns/5dm5sECfESM0 AcnZm6TcU2QTgTQzEp0hqnW3ze6814EK5ZWdbMzfsxM/+I66zW62GsBBa2smOd/RcO WESLzg5rB0QudlMQXagwF7hmfSPWO3ObBtIWGWzVKtwXXd3Dv5abrT1OUYcifGV9JI 6hEue9Y2pOdiNEndCtsePY6Yd0sQf2eXXJ5Ty734Kx0aU82d5uieCpTu9JKwm6lGxc 7v6Ol9qwMB++g== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 97DD9442FF9 for ; Thu, 7 Dec 2023 11:42:19 -0500 (EST) Received: from pastel (unknown [45.72.194.97]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 704F0120301 for ; Thu, 7 Dec 2023 11:42:19 -0500 (EST) From: Stefan Monnier To: bug-gnu-emacs@gnu.org Subject: 30.0.50; Help deal with multiple versions in load-path X-Debbugs-Cc: monnier@iro.umontreal.ca Date: Thu, 07 Dec 2023 11:42:12 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.025 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Package: Emacs Version: 30.0.50 With packages being available both as bundled with Emacs and as ELPA packages, it has become a lot more common place to have two versions of a package in the `load-path` and to have to deal with situations where the "incorrect" version has been loaded before `load-path` was changed. These kinds of problems manifest in various ways and we try to circumvent them in `package.el` in some cases but that can't cover all cases. I suggest we introduce a new function to help packages susceptible to those problems. The patch below introduces a new function which I tentatively called `require-with-check` and shows how it could be used in the case of `eglot.el` (which relies on several core packages also distributed via GNU ELPA and currently uses a hack which slows it down unnecessarily in the normal case). As mentioned in a FIXME in there, maybe we should also consider adding to `seq` (and `eldoc`) something like ;;;###autoload (if (featurep 'seq) (require-with-check 'seq 'reload)) -- Stefan --=-=-= Content-Type: text/x-diff; charset=utf-8 Content-Disposition: inline; filename=require-with-check.patch Content-Transfer-Encoding: quoted-printable diff --git a/lisp/files.el b/lisp/files.el index 1cdcec23b11..e1e885462ce 100644 --- a/lisp/files.el +++ b/lisp/files.el @@ -1246,6 +1246,29 @@ load-library (interactive (list (read-library-name))) (load library)) =20 +(defun require-with-check (feature &optional filename noerror) + "If FEATURE is not already loaded, load it from FILENAME. +This is like `require' except if FEATURE is already a member of the list +`features=E2=80=99, then we check if this was provided by a different file= than the +one that we would load now (presumably because `load-path' has been +changed since the file was loaded). +If it's the case, we either signal an error (the default), or forcibly rel= oad +the new file (if NOERROR is equal to `reload'), or otherwise emit a warnin= g." + (let ((lh load-history) + (res (require feature filename (if (eq noerror 'reload) nil noerro= r)))) + ;; If the `feature' was not yet provided, `require' just loaded the ri= ght + ;; file, so we're done. + (when (eq lh load-history) + ;; If `require' did nothing, we need to make sure that was warranted. + (let ((fn (locate-file (or filename (symbol-name feature)) + load-path (get-load-suffixes)))) + (cond + ((assoc fn load-history) nil) ;We loaded the right file. + ((eq noerror 'reload) (load fn nil 'nomessage)) + (t (funcall (if noerror #'warn #'error) + "Feature provided by other file: %S" feature))))) + res)) + (defun file-remote-p (file &optional identification connected) "Test whether FILE specifies a location on a remote system. A file is considered remote if accessing it is likely to diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el index d410367f902..8124a3f52e0 100644 --- a/lisp/progmodes/eglot.el +++ b/lisp/progmodes/eglot.el @@ -116,13 +116,16 @@ ;; having installed them, didn't correctly re-load them over the ;; built-in versions. (eval-and-compile - (load "project") - (load "eldoc") - (load "seq") - (load "flymake") - (load "xref") - (load "jsonrpc") - (load "external-completion")) + ;; For those packages that are preloaded, reload them if needed, + ;; since that's the best we can do anyway. + ;; FIXME: Maybe the ELPA packages for those preloaded packages should + ;; force-reload themselves eagerly when the package is activated! + (require-with-check 'eldoc nil 'reload) + (require-with-check 'seq nil 'reload) + ;; For those packages which are not preloaded OTOH, signal an error if + ;; the loaded file is not the one that should have been loaded. + (mapc #'require-with-check + '(project flymake xref jsonrpc external-completion))) =20 ;; forward-declare, but don't require (Emacs 28 doesn't seem to care) (defvar markdown-fontify-code-blocks-natively) @@ -138,11 +141,12 @@ tramp-use-ssh-controlmaster-options 'eglot-managed-mode-hook "1.6") (define-obsolete-variable-alias 'eglot-confirm-server-initiated-edits 'eglot-confirm-server-edits "1.16") -(define-obsolete-function-alias 'eglot--uri-to-path 'eglot-uri-to-path "1.= 16") -(define-obsolete-function-alias 'eglot--path-to-uri 'eglot-path-to-uri "1.= 16") -(define-obsolete-function-alias 'eglot--range-region 'eglot-range-region "= 1.16") -(define-obsolete-function-alias 'eglot--server-capable 'eglot-server-capab= le "1.16") -(define-obsolete-function-alias 'eglot--server-capable-or-lose 'eglot-serv= er-capable-or-lose "1.16") +(define-obsolete-function-alias 'eglot--uri-to-path #'eglot-uri-to-path "1= .16") +(define-obsolete-function-alias 'eglot--path-to-uri #'eglot-path-to-uri "1= .16") +(define-obsolete-function-alias 'eglot--range-region #'eglot-range-region = "1.16") +(define-obsolete-function-alias 'eglot--server-capable #'eglot-server-capa= ble "1.16") +(define-obsolete-function-alias 'eglot--server-capable-or-lose + #'eglot-server-capable-or-lose "1.16") (define-obsolete-function-alias 'eglot-lsp-abiding-column 'eglot-utf-16-linepos "1.12") (define-obsolete-function-alias --=-=-=-- ------------=_1703866981-20172-1--