Straight.el: gccemacs update - solving "emacs-version-changed"

[VanLaser]

On my Arch Linux machine, I use an "emacs native compilation branch" package (from the archlinuxcn repository), and I recently switched to straight.el for package management ("develop" branch). Every time my emacs package gets updated, straight.el bails out with 'emacs-version-changed'. This, I found out to be caused by natively compiled files left over from the before-the-update emacs binary, in the "~/.emacs.d/eln-cache" folder (see 'comp-eln-load-path' variable doc). So, I fixed it using a slightly changed version of the bootstrap sequence recommended on straight.el homepage, as follows, to delete that folder (the bottom part):

(setq load-prefer-newer t)
(setq straight-repository-branch "develop"
      straight-vc-git-default-clone-depth 1)

;;; package manager bootstrap
(defvar bootstrap-version)
(let ((bootstrap-file
       (expand-file-name "straight/repos/straight.el/bootstrap.el" user-emacs-directory))
      (bootstrap-version 5))
  (unless (file-exists-p bootstrap-file)
    (with-current-buffer
        (url-retrieve-synchronously
         "https://raw.githubusercontent.com/raxod502/straight.el/develop/install.el"
         'silent 'inhibit-cookies)
      (goto-char (point-max))
      (eval-print-last-sexp)))
  ;; catch emacs updates that have native compiled leftovers
  (unless (catch 'emacs-version-changed
        (load bootstrap-file nil 'nomessage))
    (when (boundp 'comp-eln-load-path)
      ;; remove leftovers, with confirmation just to be safe
      (when (yes-or-no-p (format "Delete '%s'?" (car comp-eln-load-path)))
    (delete-directory (expand-file-name (car comp-eln-load-path)) t))
      ;; and try again
      (load bootstrap-file nil 'nomessage))))

Now (finally!) the question: is that the solution? In other words, who's responsible for dealing with that error: a) should straight.el not check for that mismatch, b) is it ok if I do it there, or c) should the package installer remove that folder for me (but, since it's customizable from my init.el, how could it know what folder to delete, in this case)?

I know 'straight.el' is actually checking for compiled files mismatch, but the native compilation is adding an extra layer of 'compiled' in the mix.

---

I'm not suggesting the above code is the solution, since I believe straight.el is checking for any type of compiled file leftovers (not only the native ones). Maybe there is a way to check specifically for native compiled files leftovers (and in that case delete the eln-cache)?

[progfolio]

Thank you for bringing this to our attention.
I'm not currently using the native-comp branch, but what you're running into makes sense.
If the eln file is preferred over the elc, then it could become stale after upgrading Emacs.

@flatwhatson: Have you run into any similar scenarios? Does this solution look reasonable to you?

As far as prompting whether or not to remove the eln files, I think that's safe to skip.
If the Emacs version has changed, you generally want to re-compile all elc/eln files, as the upgrade may have introduced incompatibilities. You can usually get away without doing this, but it depends on what has changed on Emacs' end.

[raxod502]

If I'm understanding the issue here, the correct solution is most likely to adjust the code in bootstrap.el that does some manual management of the file straight.elc, so that it also takes into account the possible existence of straight.eln.

[raxod502]

Removing waiting on response because it seems there definitely is a problem that needs to be solved, independent of further information being provided.

[flatwhatson]

Sorry, I haven't encountered this error because I use straight via Doom Emacs which bypasses that check in bootstrap.el.

I think that extending the existing bootstrap logic for stale elc to also handle rebuilding the eln makes sense.

I'm not sure whether straight should enforce or even encourage deletion of the eln cache directory, even though this is currently common practice. The native-compilation feature has its own logic for managing outdated eln files which should also handle version upgrades, it's just that each new commit on the feature/native-comp branch doesn't constitute a "version upgrade".

[azzamsa]

Same here.

I am using feature/native-comp branch. and after git fetch and compiling. I get No catch for tag: emacs-version-changed, nil.

Instead of modifying bootstrap.el, I rush to delete eln-cache directory. Solved.

[raxod502]

It seems to me like updating to a new commit on feature/native-comp should result in the compiled files being rebuilt. What if there was a bug in the previous version of feature/native-comp that has been fixed, for example? If feature/native-comp has its own logic for managing outdated compiled files, as @flatwhatson mentions, but straight.el wants to be more granular about when the cache is cleared, it seems reasonable to take care of that on the straight.el side.

I think, in bootstrap.el, all we would have to do is update the (when emacs-version-changed ...) clause to also delete anything related to .eln files.

[aaronjensen]

Updated https://github.com/raxod502/straight.el/issues/697 which can be merged into this, I think

[progfolio]

729 should fix this.