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 ?

Improve this question
4
  • 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, 2015 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, 2015 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, 2015 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, 2015 at 1:32

1 Answer 1

Reset to default
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).

Improve this answer
4
  • This looks like the relevant commit.
    – politza
    Jan 28, 2015 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, 2015 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, 2015 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, 2015 at 12:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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