bug#73681: Maybe partly undo the patch on Elisp comp-el-to-eln-filename

[Liliana Marie Prikler]

Am Montag, dem 07.10.2024 um 22:46 +0200 schrieb Martin Edström:
> In my package, the use case is instead that it starts sub-processes,
> each of which should load a file "org-node-parser.eln".  I could ahve
> made them just load the output of (locate-library "org-node-parser"),
> but for unrelated reasons, that seems it would only ever locate an
> .elc and not an .eln.
Could you keep track of modifications to org-node-parser and recompile
that on change?  Or is it part of your package already – if the latter,
then we should already have it compiled as a package.

> So I need to use `comp-el-to-eln-filename` to find the up-to-date
> .eln (or force it to be compiled).  Regardless of whether or not the
> rest of the package has already been native-compiled.
> 
> The worst-case scenario is using package version 1.4.1 in the main
> Emacs process, but 1.4.0 of org-node-parser.eln in the subprocesses. 
> That leads to unintended bugs.
> 
> I suppose the other way around could also happen - using package
> version 1.4.0 but 1.4.1 in the subprocesses - but that'll be my own
> mess to figure out :)
I think it's your own mess either way – can't you downgrade to a model
where you just ask for "org-node-parser" to be loaded, regardless of
compilation?  Then, you wouldn't have to native-compile it. 

> > We write store paths to a subdirs.el – unless specifically prompted
> > to reload that, Emacs will keep using old libraries.  This is by
> > design, so that updating Emacs does not cause any issues with
> > (byte) compiled files.
> 
> Let me know if I understand this correctly: updating a package
> compiles it at the same time, so we can have store paths like
> 
> /gnu/store/package-1.4.0/...{.elc,.el,.eln}
> /gnu/store/package-1.4.1/...{.elc,.el,.eln}
> 
> which sounds like it will be all consistent.  An .eln in the second
> directory would never secretly be 1.4.0, for example.
> 
> But since you said we disabled the JIT compilation, and store dirs
> are read-only, where do the .eln actually end up, after the user
> starts Emacs and it does its async-native-compile thing?
> 
> (or does it not do any JIT compilation at all?)
We don't do JIT, but even if we did, we should find the one in the
store (and the correct one, as per Emacs load paths).

> I don't have a Guix machine at the moment, but is it a deterministic
> path like ~/.emacs.d/eln-cache/29.4-HASH/package-HASH.eln ?  The user
> in my GitHub issue gets no such path from running `comp-el-to-eln-
> filename`, but maybe they're on an old Guix Emacs.
It's `~/.emacs.d/eln-cache/29.4-HASH/some/module.eln`, with some/module
being the module that you'd load.

Cheers