Re: org-assert-version considered harmful

[Ihor Radchenko]

Stefan Monnier <monnier@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