From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#67696: 30.0.50; Help deal with multiple versions in load-path Date: Sat, 16 Dec 2023 14:50:34 -0500 Message-ID: References: Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32843"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 67696@debbugs.gnu.org To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Dec 16 20:51:32 2023 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 1rEahA-0008OD-AC for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Dec 2023 20:51:32 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rEagg-0004Aj-VW; Sat, 16 Dec 2023 14:51:02 -0500 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 1rEagf-0004AW-7s for bug-gnu-emacs@gnu.org; Sat, 16 Dec 2023 14:51:01 -0500 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 1rEage-0000ff-Vs for bug-gnu-emacs@gnu.org; Sat, 16 Dec 2023 14:51:00 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rEagf-0007wM-NN for bug-gnu-emacs@gnu.org; Sat, 16 Dec 2023 14:51:01 -0500 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 67696-submit@debbugs.gnu.org id=B67696.170275624830493 (code B ref 67696); Sat, 16 Dec 2023 19:51:01 +0000 Original-Received: (at 67696) by debbugs.gnu.org; 16 Dec 2023 19:50:48 +0000 Original-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 Original-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 Original-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== Original-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) Original-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) In-Reply-To: (Stefan Kangas's message of "Sat, 16 Dec 2023 11:07:23 -0800") 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:276377 Archived-At: >> 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