Stefan Monnier <monn...@iro.umontreal.ca> writes: >> 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.
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. > 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 :-) I understand. As Timothy proposed, we can make less strict checks for Org version consistency. But the question is whether we really need to make a more lax assertion or maybe it is better to keep the assertion as is and use it to catch potential issues e.g. in Elpa. > 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` :-) Indeed. Version mismatch issue has been fixed in package.el years back. But it is starting to pop up again as alternative package managers are getting traction. There is a constant influx of bug reports caused by mixed installation. Especially by users of Doom Emacs and straight.el. Unfortunately, the problem cannot be easily solved, say, on straight.el side --- straight.el basic design is causing the issue to appear. > 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. 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. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
