Byte-compile packages in child Emacs process

[raxod502]

Otherwise, the compilation is affected nondeterministically by the state of the running Emacs. Hasn't bit me yet, but I know it will someday.

[slippycheeze]

Forgive the drive-by comment, but the async package provides this facility natively. Might save you time and trouble to reuse that feature.

[cyruseuros]

Just leaving this here for how the async package @slippycheeze mentioned does it:
https://github.com/jwiegley/emacs-async/blob/master/async-bytecomp.el#L137

[thierryvolpiatto]

Yes async package provide async-byte-recompile-directory that you can use safely instead of
byte-recompile-directory, this will avoid bugs when packages rename macros, variables etc...
We are using this with Helm since long time now, Magit use this too.

[raxod502]

Hasn't bit me yet, but I know it will someday.

Looks like "someday" turned out to be a little over three years: #624 (comment)

Eh, could have been worse---I'll take it.

[thierryvolpiatto]

Radon Rosborough <[email protected]> writes:

Hasn't bit me yet, but I know it will someday. Looks like "someday" turned out to be a little over three years: #624 (comment) Eh, could have been worse---I'll take it.

Didn't follow the full thread, but it seems it is about compiling packages async. Compiling packages async is needed with package.el which does the compilation of packages straight after fetching them i.e. while the old package version is still loaded, it is here the problem happen if e.g. a macro is modified/renamed in new package, I made `async-bytecomp-package-mode` (see https://github.com/jwiegley/emacs-async/blob/master/async-bytecomp.el#L151) for this reason. I am new to straight.el and haven't yet looked at its code carefully, but it seems the packages are recompiled when emacs restart, so at this point the old version of package is no more loaded and IMHO there is no need to compile it async because you can't hit the problem described above, but maybe it is because I always restart emacs after calling `straight-pull-all`? But what about people using `straight-rebuild-package` or `straight-rebuild-all` (not good IMO unless you know what you are doing)? Thanks for straight.el.

…

-- Thierry

[raxod502]

You are correct in that the specific package.el problem that you describe does not also happen with straight.el, unless you use straight-rebuild-package. However, there are other issues. One is that byte-compiling a package causes it to be loaded. This means that in some inits, a package will be eagerly loaded, while in others, it won't be. This is bad for reproducibility, because sometimes a package being eagerly loaded can either surface or hide a bug. Another issue relates to a complex tangle of Org things, which is described in #624 (comment) as I mentioned earlier.