From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id MI4QDlWFIGO1WwAAbAwnHQ (envelope-from ) for ; Tue, 13 Sep 2022 15:27:49 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id CJUPDVWFIGMPzgAAG6o9tA (envelope-from ) for ; Tue, 13 Sep 2022 15:27:49 +0200 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 67E3D3350E for ; Tue, 13 Sep 2022 15:27:48 +0200 (CEST) Received: from localhost ([::1]:48078 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oY5x4-0002na-Tm for larch@yhetil.org; Tue, 13 Sep 2022 09:27:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40960) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oY5w8-0002nR-VM for emacs-orgmode@gnu.org; Tue, 13 Sep 2022 09:26:48 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:34851) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oY5w3-00044V-3L for emacs-orgmode@gnu.org; Tue, 13 Sep 2022 09:26:45 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id ECF9044121A; Tue, 13 Sep 2022 09:26:40 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 933624407DC; Tue, 13 Sep 2022 09:26:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1663075599; bh=C49RMivFoNsOk3AOBRuFwl9jmTbXjAPNzEdJU0tNvUk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=RP7PsjTDvTDu9I8nwHydL2cbXHNk+TJYOxMRG1PqdiDsHVI0rDxta7pENprPu3nLo 5SllZsn1sFOd91Rl5g0bt2b+3vbhcYIp1F5yiXAnYbgWrZeQkQj6mLSiGXx1/hEAWu 3Urh5T9ddBaAZ+Wc0Cfe3aRcCzDwqWyZ5HMMpKXGd7uznXkrz1a+j6rK9GFvELCKbm ctagWFOx5RNUdQQvAIy2QBa+l042zmvRM5WCzzXZIgFxcDHMZPk9XDEoNcoi1Jyj+E hmEt/CSQRm0TbtrKXqGGhISxLo5gmNck8UFfViViKQWagQr+CPdcCg3Dz9+nVFiK2z 6eYF4VQ8bVilw== Received: from pastel (unknown [157.52.9.190]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 44AB2120D57; Tue, 13 Sep 2022 09:26:39 -0400 (EDT) From: Stefan Monnier To: Ihor Radchenko Cc: emacs-orgmode@gnu.org Subject: Re: org-assert-version considered harmful In-Reply-To: <87h71ct10n.fsf@localhost> (Ihor Radchenko's message of "Tue, 13 Sep 2022 11:18:48 +0800") Message-ID: References: <875yhsujkq.fsf@localhost> <87h71ct10n.fsf@localhost> Date: Tue, 13 Sep 2022 09:26:38 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1663075669; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=tVVnE2Vaxer/l/k/M1NNxN6572NmS65xBfpagteGc3M=; b=EdkwOo0tgxEqhKPCLM58AUORAQVf9fPjDC0ajYTix9wkCPLWH5XlnRbTfP24frqb2BNOt4 d5jUOzPgvxA4IPZBcf0VSuqZbgKtlQoROo8wVRUAA6zHmofz8r5cKBy81nllwBzpHCyCWx KbdmKhvw1S0lV2DaiYkPKsLTH4vx72emBx7wYQx/vSIHlG/K8sk0ERxNNAQqo51WcUWbMm ixJeh0GV8RK/OdWCK5+hcGMm+vObC5Tq1eCZoslgeK5zJgbumrynVAUCjHVKq9veYhSosB GxyuY09Rq2VFIemzKIt2A8+OnANZ1a30OnSnIF0tTHDcK1fendAAsAXa7ccioQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1663075669; a=rsa-sha256; cv=none; b=fhmA5D6ZaHz0lsHNVHKGzQxXHJLjNeHEKiIyjH5OvwWq0XmoNi4kLOp3gFWDpKnTfwbYnk feNBUi1gRe/UJl88Ed7QEwdi7fgg3wlaaA3Zu6w5zH6h/2snX5UCnVk4QhWrsPXH+7mQX1 xuqFT1yL+sALfFk/NI+MN2NztVTG0+rE2biXDNKIxoo4QRSksMFXaE8CERbugI/2R4yJWR vOwBacbIjG1+f3EPfLyuK/o4Lw/ADg9yg4ic4aYlDuB8CeWVbfnGojwdICwV8DELESG9nI 0Yb2oDochn6geb07meoDapvsFNUvzjO9s+cPfFl8SzJKbZcEo+pTFCr+GfXXNg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=iro.umontreal.ca header.s=mail header.b=RP7PsjTD; dmarc=pass (policy=quarantine) header.from=iro.umontreal.ca; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -5.01 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=iro.umontreal.ca header.s=mail header.b=RP7PsjTD; dmarc=pass (policy=quarantine) header.from=iro.umontreal.ca; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 67E3D3350E X-Spam-Score: -5.01 X-Migadu-Scanner: scn1.migadu.com X-TUID: XQv1K7ZrpX0O >> - git pull => switches to 9.5.5, but several .el files are left unchanged. >> - make autoloads => this refreshes the autoloads, but the .elc files >> of those .el files which didn't change still won't be recompiled. > > Isn't it a bug in the elpa scripts then? > If a macro definition is changed and the .elc file using that macro is > not changed, it still needs to be re-compiled. Otherwise, all kinds of > unexpected side effects may appear. Yup. But there's no option to automatically find those dependencies in ELisp, and (IIRC from last time I looked at it, in many packages obeying such dependencies would end up introducing circular dependencies in the Makefile), so we'd have to depend on the package's author to provide a working set of file dependencies. Note that the same problem applies to Emacs's own ELisp files. In Emacs we have `make bootstrap` to manually get out of such a bad compilation. >> PPS: Maybe instead of calling `org-assert-version` everywhere, the >> `org-autoloads.el` (i.e. the file that sets up the `load-path` and >> the autoloads) could look for traces of Org files in the >> `load-history` and signal an error if such files are found coming >> from a different directory. > > No, unfortunately. > > org-autoloads, when loaded from built-in Emacs version will not help > to catch newer Org libraries being loaded after built-in Org version is > loaded. Hmm... after new-org-autoloads.el is loaded, the old-Org files will be relegated to "late in the `load-path`" (i.e. after the directory that holds the new-Org file) and should hence not be loaded any more (unless someone goes through the trouble to explicitly load an old-Org files with an absolute file name). > Moreover, I consider loading personal forks of built-in Org libraries a > valid use-case. Demanding all the org libraries to be loaded from the > same directory will limit this possibility. As long as they're loaded after new-org-autoloads.el, it would still be fine since the test is only performed once when loading the new-org-autoloads.el. Stefan