背景

我每天都使用emacs，但主要用于完成任务。除了添加软件包之外，我真的不喜欢自定义它，也不喜欢进行故障排除。我希望emacs像一个好的OS一样淡入背景，然后继续发展。不久前，我发现它 el-get允许我安装所需的软件包，这些软件包不可用，package.el并且还提供了更多控制权，例如选择maint组织模式的分支，而不是可能会造成临时问题的边缘漏洞。现在我不确定是否应该使用el-get。

题

el-get似乎是解决各种存储库和emacs黑客的好方法。它提供了根本无法实现的功能package.el。现在，package.el在较新的emacs（>=24.4）版本中支持多个存储库，el-getemacs的内置软件包管理器有哪些用例和类似的替代方案？

ELPA仍然有些事情是不可能的，ELPA总是有些事情是不可能的，因为它们不符合ELPA的概念：您永远无法通过来自派生的哈希来安装特定的提交资料库。同样，在安装软件包之前，您将永远无法对软件包应用自定义本地补丁。这些功能完全超出了ELPA的范围，如果您需要它们，则必须使用替代的软件包管理器。

我认为，尽管如此，el-get如今已成为一种传统解决方案。鉴于ELPA已成为Emacs的事实上的标准软件包管理器，其他软件包管理器应与ELPA无缝集成。但是，el-get不会将其自身的程序包公开给ELPA，这意味着它的程序包对于ELPA完全不可见，并且ELPA程序包永远不能依赖el-get程序包，这对依赖项管理有明显的影响。

如果您需要ELPA以外的功能，则现在应该关注QUELPA而不是el-get。

我为Emacs编写了一个新的程序包管理器straight.el，它试图改进所有现有的程序包管理解决方案。文档中有一个广泛的部分，与其他程序包管理器进行比较，但这是一个很简短的摘要：straight.el

• package.el从中央服务器下载不透明的tarball，没有选择软件包特定版本的选项，并且不允许您对软件包进行本地更改；在上游做出改变是不可能的。straight.el以分散的方式克隆Git存储库（但如果需要，它会自动使用MELPA，GNU ELPA和EmacsMirror的配方），并允许您对其进行任意本地更改，提交这些更改并向上游提供帮助。这可以手动完成，也可以使用内置的批量存储库管理操作。程序包的更改会自动检测到，不需要手动重建。此外，straight.el 支持Emacs配置的完全可重复性，因为它允许您编写一个修订锁定文件，其中包括所有软件包的Git哈希。
• Quelpa和Cask都基于package.el，并且继承了许多相同的缺点。例如，Cask没有安装特定版本的软件包的任何概念。Quelpa确实这样做，但是它要求您将Git哈希硬编码到您的init文件中。完全straight.el避免package.el使用适用于更多用例的统一设计替换其所有核心功能。
• el-get的优势在于，您可以从绝对的任何地方安装软件包（所有已知的版本控制系统，任意HTTP，系统软件包管理器，EmacsWiki甚至go get！？）。但是，通过支持这么多资源，el-get无法提供提供的那种高级软件包管理操作（例如，通过修订锁定文件和交互式存储库管理操作的可再现性）straight.el。straight.el仅支持Git，因为大多数软件包都可以通过Git获得，而那些软件包则不能通过EmacsMirror获得（我敢于您找到一个不可能的软件包！）。请注意，straight.el不过，如果需要，可为将来添加的其他版本控制后端（例如，用于Mercurial）提供可扩展的API。
• 博格的哲学非常相似，straight.el并具有许多相同的优点。然而，它的目的不是要成为一个完整的软件包管理器，旨在与其他工具，如关注使用epkg，auto-compile和Magit。相反，它straight.el是自包含的，可以单独提供您所需的一切，几乎不需要甚至不需要其他配置。另外，Borg使用Git子模块，其接口具有一些粗糙的边缘，而straight.el使用独立管理的Git存储库，从而产生了更多的灵活性和功能。
• 也有手动方法，但我不建议这样做。在头几个月之后，您将彻底改造Borg。然后在接下来的几个月中，您将被彻底改造straight.el。不过，您会学到很多有关软件包管理的知识；）

尽管有优点和缺点，但我认为el-get仍然有意义，尽管@lunaryon（也有rejeep）的强烈意见。

我将raw package.el与use- package一起使用了一段时间（2至3年），然后切换到el-get，然后切换为Cask。几天前我回到了el-get。像许多其他软件包一样，在package.el之前，我是手动处理加载项。

为什么我回到el-get？我遇到了一些Cask怪异的事，因为它不是git repo（我的Github软件包，不在MELPA中），而该软件包实际上是在使用git ... el-get config，我很高兴马上就去。

我不喜欢el-get的几件事：

• 它支持多个提取程序，而不仅仅是git。
• 它包含足够的预定义配方
• 在启动时比Cask快。
• 是的，@ lunaryorn，Wiki并不是分发代码的地方，但是如果emacsmirror（Github）上没有克隆，我仍然不想创建Github 仓库。
• 自包含，对于Cask，您需要外部安装。我使用单个初始化文件（不是模块化配置） allout模式来浏览各个部分。
• 埃尔盖特从用户角度来看，很简单。

注意：我正在OSX和Linux下运行Emacs Git HEAD。

您可能想看看paradox。它不是另一个程序包管理器，而是一个更整洁的前端package.el。例如，更新软件包时，它询问您是否要安装它们并一步删除旧的软件包。

如果使用它，则可能要在init文件中设置paradox-execute-asynchronously为t。