软件包维护者不使用Emacs软件包管理器的技术考虑？

我注意到一些著名的软件包维护者选择不使用Emacs软件包管理系统（ESS？）或抱怨其局限性（Helm）。

引用Helm的README.md：

警告：由于package.el的概念不正确，该概念负责获取helm文件并对其进行编译，因此从melpa和list-package升级时，大多数时间用户都出错。为了避免这种异步现象，已添加了对Helm的依赖关系，以强制package.el在干净的环境中编译其文件。从git安装并使用make文件的人不会遇到这个问题，尽管建议使用Async，但是它不需要Async，因为它修复了所有其他可能由（m）elpa的package.el安装的软件包的安装。有关更多信息，请参见常见问题解答。

当前的软件包管理系统可能暗示哪些确切的技术限制async？为什么需要将软件包用作依赖项？

您所指的问题可能是，当您从已经在使用该软件包的Emacs会话中升级该软件包时，该软件包的旧版本有时会在新版本的编译过程中产生干扰，从而导致文件编译错误。

Emacs-25中有一个临时性修复程序，但AFAIK在24.5中仍然存在该问题。

除了ProofGeneral明显例外，我不知道某些ELPA档案文件中没有任何主要的Emacs软件包。特别是，自三年以来，ESS就在MELPA上。PG本身就是一个故事，绝对不能代表整个Emacs生态系统。

ELPA肯定有其缺陷，但是对于绝大多数的程序包来说，它工作得很好，即使对于像Magit这样的大型程序包也是如此。Helm是我看到的唯一抱怨ELPA的包裹。我不确定他们到底在抱怨什么，但是我想这与编译有关：

在升级期间，Emacs在仍加载旧版本的环境中编译软件包的新版本。通常，这完全没有害处，但是在某些情况下会破坏宏。Emacs将针对宏的旧实现编译新版本，如果新代码依赖于该宏中的特定更改，则可能导致破坏。

作为我自己的软件包维护者，我几乎不同意这一说法。我倾向于指责头盔而不是ELPA或Emacs。在我看来，该语句是夸张的，而且问题只是过度使用和滥用宏的症状。

如果您使用大量宏，甚至将更平凡的代码放入宏主体中，则只需要了解其对字节编译的影响即可，并且必须小心保持与自己的宏的向后兼容性在您的包裹中。不这样做，而要怪罪别人，这不是一件好事。我的2美分。