Am Dienstag, dem 08.10.2024 um 12:41 +0200 schrieb Martin Edström: > It comes as part of the package. I don't want to assume that it has > been compiled, since it's fairly performance-sensitive. That's why > I'll either use a previously existing compiled object or make a new > one. Could you leave that decision to the user?
> […] > > So let's ignore my package, it is just an example of a downstream use > of `comp-el-to-eln-filename` that relied on its hashing > functionality. > > Let's just discuss that function. > > I have to point out that the emacs `load-path` does not include any > native paths. When I inspect the value on my non-Guix emacs, I see > no references to .../eln-cache/..., just references to directories > where there are .elc and .el files. There is a separate load path for natively compiled files, called `native-comp-eln-load-path'. > I infer that Emacs starts with finding a library in load-path, then > converts the path with `comp-el-to-eln-filename`, and checks if that > file exists, then loads it. > > And crucially, it is not just about the filepath, the function hashes > the file contents as well. That ensures that the output path is > always different if the source file changes. I think relying on such implementation details is perhaps permitted if it's inside of Emacs itself, but even then it clashes with our expectation that Emacs be graftable. > Since Guix has a patch that removes this effect, it seems like a > package could be upgraded many, many times, without the .eln path > ever changing, and so the user would stay on that very outdated file. > > Is that not a regression/bug? The way our load paths are set up, it is actually the opposite (which still is a bug, just not the one reported). While `guix upgrade` or a command to the similar effect will swap out the .eln under the hood, the `.el` and `.elc` files stay stable – remember what I wrote in the previous message about that having caused issues with byte compilation? We also get a similar-looking bug if our packages aren't actually native-compiled, but Emacs itself vendors them. That is resolved by dropping those .eln-files from the Emacs package. Cheers
