10

I am noticing some notable package maintainers are choosing to not use the Emacs package management system (ESS?) or complaining about its limitations (Helm).

Quoting from Helm's README.md:

WARNING: Due to a bad concept of package.el which is in charge of fetching helm files and compiling them, users had errors most of the time when upgrading from melpa and list-package. To avoid this Async have been added as dependency to helm to force package.el compiling its files in a clean environment. People installing from git and using the make file will not suffer from this problem and don't need Async though it is recommended as it fix installation of all other packages you may install with package.el from (m)elpa. See FAQ for more infos.

What exact technical limitations does the current package management system has that they could be alluding to, and why would packages need to use async as a dependency?

Improve this question
4
  • 1
    This question should be closed as too broad for this site, I think. It is better aimed at a discussion forum. Try [email protected] or [email protected] or Emacs reddit or some such. "What is the problem exactly?" assumes there is one such problem, and asking what the possible problems are for any package (or any package maintainer) is too broad.
    – Drew
    Commented Jun 30, 2015 at 14:51
  • 2
    ESS is hosted on Melpa: melpa.org/#/ess, maybe it's just a documentation thing. I know many projects, which are typically installable through a system package manager, but choose not to mention that option for no real reason (maybe assuming that if you went as far as downloading the sources / binaries from the site, then you must have a reason to do it). I don't know what problem Helm had.
    – wvxvw
    Commented Jun 30, 2015 at 14:51
  • Your title reads a little odd to me. Did you mean to write "managers" twice, or did you mean maintainers?
    – Malabarba
    Commented Jul 2, 2015 at 13:16
  • 1
    Writing as an ESS developer, do let us know how we can improve matters -- as others have commented, ESS is in MELPA.
    – Stephen Eglen
    Commented Jul 18, 2015 at 14:23

2 Answers 2

Reset to default
19

The problem you're referring to is probably that when you upgrade a package from within an Emacs session where that package is already in use, the old version of the package will sometimes interfere during compilation of the new version, leading to miscompiled files.

There is a tentative fix for that in Emacs-25, but AFAIK the problem is still present in 24.5.

Improve this answer
9

With the notable exception of ProofGeneral, I'm not aware of any major Emacs package that's not available in some ELPA archive. Specifically, ESS is on MELPA since three years. And PG is a story on its own, and definitely not representative for the whole Emacs ecosystem.

ELPA surely has its flaws, but for the vast majority of packages it works just fine, even for larges ones such as Magit. Helm is the only package that I see complaining about ELPA. I'm not sure what exactly they complain about, but I guess it's about compilation:

During upgrades Emacs compiles the new version of the package in an environment where the old version is still loaded. Normally, this does no harm at all, but it can break macros in certain situations. Emacs will compile the new version against the old implementation of the macro, which can cause breakage if the new code relies on a specific change in that macro.

Being a package maintainer myself, I pretty much disagree with this statement, though. I tend to blame Helm rather than ELPA or Emacs. In my opinion the statement is hyperbole, and the issue but a symptom of over- and ab-using macros.

If you use a lot of macros and—even worse—put non-trivial code into the body of macros you simply have to be aware of the implications this has for byte compilation and you have to be careful to maintain backwards compatibility with your own macros within your package. Not doing so, and instead passing blame around, is not a very nice thing to do. My 2 cents.

Improve this answer
3
  • 2
    FWIW, I disagree with your disagreement: while I agree that it's better to try to avoid overusing macros, the compilation problems are real and can affect more than macro calls (e.g. they affect can be triggered by inlinable functions as well, or by functions called during macro-expansion). And when you get bitten by this problem, your .elc files are incorrect and can misbehave in all kinds of interesting ways, so it can be difficult to diagnose the problem, and fixing it requires uninstalling+reinstalling the package (once you've figured the problem and which package needs to be reinstalled.
    – Stefan
    Commented Jul 4, 2015 at 18:04
  • 1
    @Stefan I do not deny the compilation issues. I got bitten myself. But I dislike the attitude that shines through this statement, and the lack of what I'd call a "balanced point of view". Helm gets bitten that bad because they've made many mistakes on their side, too, but their statement does not acknowledge that. In my humble opinion calling functions in macro body is such a mistake. Macros are for syntax only, but never for functionality. But I do understand that this seems to be a subject on which the Emacs Lisp community has many different opinions.
    – user227
    Commented Jul 4, 2015 at 18:32
  • ropemacs, jdee-emacs and excorporate are notable packages that aren't on any ELPA archive (depending on your criteria for major packages). The vast majority of packages are, though.
    – Wilfred Hughes
    Commented Aug 12, 2015 at 12:22

Your Answer

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

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