From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id cMSpIbhitWPKMAEAbAwnHQ (envelope-from ) for ; Wed, 04 Jan 2023 12:27:52 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id kImrIbhitWPbwQAA9RJhRA (envelope-from ) for ; Wed, 04 Jan 2023 12:27:52 +0100 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 33B7324F59 for ; Wed, 4 Jan 2023 12:27:52 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pD1vN-0003AD-LH; Wed, 04 Jan 2023 06:27:13 -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 1pD1vM-0003A4-HX for emacs-orgmode@gnu.org; Wed, 04 Jan 2023 06:27:12 -0500 Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pD1vK-000179-O1 for emacs-orgmode@gnu.org; Wed, 04 Jan 2023 06:27:12 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1pD1vI-0004Sn-PM for emacs-orgmode@gnu.org; Wed, 04 Jan 2023 12:27:08 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: Bug? org-assert-version does not prevent mixed install Date: Wed, 4 Jan 2023 18:27:00 +0700 Message-ID: References: <878rj47tj0.fsf@localhost> <87h6xs6b52.fsf@localhost> <87a63797yc.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Content-Language: en-US In-Reply-To: <87a63797yc.fsf@localhost> Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -2 X-Spam_score: -0.3 X-Spam_bar: / X-Spam_report: (-0.3 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-3.103, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1672831672; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=LUNU2Ho87uRMD5vEgF9LFViezUDQShfVKoEdXCl/JFA=; b=nQDPX3qcIr67hLj+FVmNsK9S7peRzEG7lKPddC+yxusJ46l1z8j6Tp+AVAlTM3C0t7mi9x xHPlXrZWewAsJAOG6ql0/KryomN3myH4aSSwQYzIQehGo2wPkXwijxvYGQEbBNCNmAf5Mn 3z/DD6YereDTxZRGe6A6s53RTZLoYA7fBy2Y6YV4SmO2Nr5JXsOtPQ50/T5QGgoAKg7j8D cDKQcOZ82MedITN6PTQalJlLdeoJyNXYAdquSU/bASNRBHtx0R09ozRgRLRd+ZRysrxpcv LTP375hf44UK0lVuaLkytFCqGBegvPVh5v7ngRC4BIzzX+MnXjodzYWOaYQRIQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; 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"; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none) ARC-Seal: i=1; s=key1; d=yhetil.org; t=1672831672; a=rsa-sha256; cv=none; b=sMDUoCQyMvUGAqR0sO0aeTl5Nhz1K4lOdIBtl5pxFHg3DxsMADGY+GCLgIUwT1e1j6jSYB tNO2UEifKUQygAjzzN+/rH0gKkyjwLdqOK1mtuJj1C477laqPGoNigcLzywjDneypAIUVD XxN7hXOa73K9j2lEluNQOsg2RoTOc2cOVIaM7Z3leTbG88+0c4W5h2lr/osQDDMwsvU2JY VS6SbkQGbzJa39kflhnz1+GNrFn5jT44Uj8ERTk9mRCui3GzXh2d0s2WpSoViUWWk7G83W RVtxeqRJ3WgOw801bTbUEajDob9jpR+61MVB+D8+TIn4LwNfVyE5QttC2pJdwg== X-Spam-Score: 2.64 X-Migadu-Queue-Id: 33B7324F59 Authentication-Results: aspmx1.migadu.com; dkim=none; 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"; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none) X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: 2.64 X-TUID: EeHqeLCgyntB Ihor, I am still puzzled why you can not reproduce messed version compilation issue. I can not figure out what I am missing. I think, the case below is easier than dealing with packages: Consider the following file compile-broken.el where ~/src/org-mode contains git main HEAD version: (load "org") (let ((org-dir "~/src/org-mode/lisp")) (add-to-list 'load-path org-dir) (byte-recompile-directory org-dir 0 :force)) remove lisp/*.elc files, run "make autoloads" and emacs -Q -l compile-broken.el It causes messed version compilation. Side note: On attempt to quit (C-x C-c) I get org-clock-kill-emacs-query: Symbol’s function definition is void: org-clocking-buffer and I had to use `kill-emacs' at this point. Exit hooks should not be so aggressive. Next session demonstrates the issue: emacs -Q -L ~/src/org-mode/lisp/ -l org There is a way to get Org completely broken. Let's simulate pulling of bundled org through some dependency and configuring new directory afterwards: emacs -Q -l org --eval "(add-to-list 'load-path \"~/src/org-mode/lisp/\")" /tmp/test.org Version mismatch is not detected, but RET causes eval-buffer: Symbol’s function definition is void: org-assert-version I have no idea how to fight with such cases. If you still can not reproduce with Emacs <= 28.1 then I may only suggest to check (locate-library "org-macs") and to remind about (list-load-path-shadows). I have no other ideas besides your environment is not clean and development Org version is available to Emacs. On 28/12/2022 16:46, Ihor Radchenko wrote: > Max Nikulin writes: >> >> Notice that `org-assert-version' works for compiled files only. > > I think that most reliable approach in this situation would be pulling > `org-assert-version' into a dedicated new file, similar to what you > suggested below. That way, we will not have feature cashes. I considered it before and discarded at first since when an Org version having such file is loaded then old version is used in the case of messed version compilation. As a result, modification of `org-assert-version' is ignored in the compiled version. I reconsidered my opinion, though I still can not get really robust problem detection. Emacs-27.1 and its built-in Org version is assumed below. Since `org-assert-version' has effect in compiled files only, we need some file with minimal dependencies that certainly will be compiled. It might be org-assert-version.el itself. However then it be required always rather than wrapped into `eval-when-compile' and should have (org-assert-version) call inside. > However, I am concerned about what is going to happen if wrong > org-version is defined during compilation. `org-assert-version' can > then be compiled with wrong org-version value and later produce similar > obscure error. If an old Org version is not loaded then the warning appears, so the assertion works. A couple of issues: - it does not suggest messed version compilation (reinstalling or removing *.elc files and recompiling) - due to long text just last paragraph about straight may be visible to the user. Perhaps it is better to expand https://orgmode.org/worg/org-faq.html#mixed-install and use a more concise message with this link. I have tried the following: - move `org-assert-version' definition to org-assert-version.el, add (org-assert-version) call to this file to have at least one file compiled. - add (require 'org-assert-version) before (org-assert-version) to other files. The warning appears unless built-in Org is loaded before adding new version to `load-path'. So we may proceed this way. Some details concerning compilation errors in the case of Emacs-27.1 and Org main: - org.el is compiled (to my surprise) - most of libraries not loaded before compilation, e.g. all ox-*.el files fails. The reason is that they require org-elemnt that requires org-persist. The latter fails to call `org-file-name-concat' (that is missed in loaded org-compat) and breaks creation of the .elc file. Finally, there is a way to not have org-assert-version.el loaded during regular sessions. Most of elisp files should have (eval-when-compile (require 'org-assert-version)) (org-assert-version) It should ensure latest `org-assert-version' definition during installing of a new Org version. The issue is that compilation of arbitrary file may fail and I am unsure if it is reasonable to introduce another file to ensure compiled variant and to require it everywehere (eval-when-compile (require 'org-assert-version)) (org-assert-version) (require 'org-assert-version-call) with org-assert-version-call.el (eval-when-compile (require 'org-assert-version)) (org-assert-version) (provide 'org-assert-version-call)