4

Let's assume there is a package P containing two files,

  P/base.el
  P/utils.el

, where the base.el file requires utils.el at runtime and utils.el contains a macro M. Upon first installation of P, package.el downloads, extracts and compiles it.

Now assume the package maintainer updated P to P' and in the process modified M to M'. The package user now attempts to update his package via package-list. Since P is a useful package, it is also loaded. Again package.el downloads and extracts P'. But I don't see how the code from the updated macro M' gets into the compiled file P'/base.el, since the feature utils.el is already provided, so, I assume, and the compiler is happy to use the old definition M.

The question I have about this is simply whether this is a correct analysis ?

  • Not hundred percent sure, but there's a good chance that (require 'package) will actually re-load and re-evaluate the package if the file is newer. So the macro definition is likely to be updated. However, the places where expansion already happened will not be updated. – wvxvw Jan 27 '15 at 22:03
  • FYI, it doesn't look to me as if require (at least as at 24.4.1) performs any such check. If the feature was registered as having been loaded, I believe that's all that matters. – phils Jan 28 '15 at 0:21
  • Obviously, explicitly loading the recompiled library would resolve the issue, and it's certainly possible that the package manager does exactly that after updating libraries which were previously loaded. – phils Jan 28 '15 at 0:25
  • 1
    @phils It doesn't do that on 24.4, but does in 25.1. Explicitly loading the file in your package is indeed a workaround. – Malabarba Jan 28 '15 at 1:32
4

But I don't see how the code from the updated macro M' gets into the compiled file P'/base.el, since the feature utils.el is already provided, [...]

It doesn't. Or, actually, it didn't.

The bug

Your analysis is correct. It was a bug in package.el, and it's been fixed on this commit for the next Emacs release. As of the next version, when package.el upgrades a package that has been loaded in this session, it will reload a package after installing it.

The workaround

One workaround is to load a package instead of requireing it. Though this is bad style, I would consider it an acceptable compromise, if you know you'll be affected by this.
You know you'll be affected by this if your package is about to make use of a newly released feature of a pre-existing macro that's on another file (or another package).

  • This looks like the relevant commit. – politza Jan 28 '15 at 11:28
  • Though, I think it's still broken, since the reloading happens after the package was compiled (with the old macros). – politza Jan 28 '15 at 12:08
  • @politza oh yes. I misinterpreted the question (I'll update the answer later) . This was fixed for macros from another package. It still needs work for macros inside the same package that are on a different file. Fortunately, the load instead of require workaround still works for that situation, and it's kind of a no brainer there. – Malabarba Jan 28 '15 at 12:16
  • And it's still listed as bug #10125. I should have checked there first, but the assumed implication of hundreds of broken packages out there kept me from doing so... – politza Jan 28 '15 at 12:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.