Re: org-assert-version considered harmful

[Stefan Monnier]

Ihor Radchenko [2022-09-13 09:52:37] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I can see the reason for this macro, and I don't really have a better
>> solution to offer, but as someone who has a Git clone of Org that is
>> regularly updated&compiled using (basically) the normal compilation
>> system used in Emacs (i.e. not systematically recompiling all the files,
>> but only those whose `.el` is more recent than their `.elc`), it means
>> that whenever Org's version changes, I have to manually erase all the
>> `.elc` files otherwise this macro will (incorrectly)
>> complain everywhere  :-(
> Does it help if you run make autoloads after git fetch?

Not that I can tell, no.  But note that I'm not using Org's makefile to
compile the files, I'm using the elpa.git scripts instead, which don't
take into account dependencies between files.

So the situation is simply something like:

- 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.

I'm not really reporting a bug; I'm not sure how to solve the problem
without throwing away the benefits of `org-assert-version`.  But I just
wanted to mention that it has unintended side effects :-)


        Stefan


PS: BTW, I notice that when Org is installed as a normal `package.el`
    package, in Emacs≥28 it will be activated before the `.emacs` file
    is loaded, which should prevent occurrence of the problems that
    `org-assert-version` aims to catch (unless you use, say, an
    org-babel file for the `early-init.el` :-)

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.