你对Emacs的包pipe理器有什么期望？
尽pipe存在几千个Emacs Lisp库，但直到24.1版本的GNU Emacs没有（内部）软件包pipe理器。
我想大多数用户会同意，find，安装和更新Emacs Lisp库是相当不方便的。
使生活变得更容易的页面
对于24.1以前的Emacs版本：
- Emacs的Lisp列表 – 问题：我看到死人（链接）。
- Emacswiki – 问题：可能包含坚果（恶意代码）的痕迹。
- Emacsmirror – 我正在使用的软件包存储库。 问题：没有包pipe理器本身支持它。
一些包pipe理器
这并不是没有人尝试过。 （当问这个问题时，其中有些问题是不存在的。）
- 自动安装
- borg.el – 使用Git子模块来同化Emacs包。
- el-get.el – 支持很多来源。
- elinstall.el
- epackage aka DELPS – 适用于Emacs Lisp包的Debian打包概念。
- epkg.el – 这现在只是一个浏览Emacsmirror的工具。
- install.el
- 安装-elisp.el
- JEM-pkg.el
- package.el – ELPA。 似乎它将包含在Emacs 24中。
更新 – package.el包含在GNU Emacs中，从版本24.1开始
- pases.el
- pelm – 命令行安装程序; 使用PHP。
- plugin.el
- straight.el – 最近和实验，尚未达到1.0版本。
- 使用-package.el
- XEmacs软件包pipe理器
包已经包含在Emacs中。 epkg还没有准备好，目前也不可用。 至lessinstall-elisp，plugin和use-package似乎不再被主动维护。
我创build了一个包含所有这些包pipe理器作为子模块的git 仓库 。
一些可能有用的工具
包pipe理者可以使用这些工具和/或他们可以用来维护包的镜像。
- date-calc.el – date计算和parsing例程。
- ell.el – 浏览Emacs Lisp列表。
- elm.el ， elx.el ， xpkg.el – 用于维护Emacsmirror 。
- genauto.el – 帮助为您的elisp软件包生成自动加载。
- inversion.el – 要求特定的软件包版本。
- loadhist.el，lib-requires.el，elisp-depend.el – 列出Emacs Lisp库依赖关系的命令。
- project-root.el – 定义一个项目根并根据它进行操作。
- strptime.el – 部分实现POSIXdate和时间parsing。
- wikirel.el – 访问Emacs Wiki上的相关页面。
关于这个问题的讨论
- emacs-devel 20080801
- comp.emacs 20021121
- RationalElispPackaging
这个问题（最后）
所以 – 我想从你那里知道你在Emacs的包pipe理器中认为重要/不重要/补充等等。
一些想法
- 许多软件包（ Emacsmirror提供了最大的软件包集合，但在任何软件包pipe理器中都没有明确的支持）。
- 只有已经过testing的软件包。
- 支持多个软件包存档（所以人们可以select多个/testing的软件包）。
- 仅依据所需function计算相关性。
- 相关性考虑了特定的版本。
- 只能使用上游发布的版本。
- 如果可用，使用版本控制系统的版本。
- 软件包被分类。
- 软件包可以卸载和更新，不仅可以安装。
- 支持创build上游版本的包的分支。
- 支持发布这些叉子。
- 支持select一个分支。
- 安装包被激活后。
- 生成自动加载文件。
- 与Emacswiki集成（请参阅wikirel.el）。
- 用户可以标记，评论等包和共享该信息。
- 只有FSF分配/ GPL / FOSS软件或不关心许可证。
- 软件包pipe理器应该与Emacs一起分发。
- 支持轻松联系作者。
- 大量的元数据。
- build议在安装特定软件包之前进行替代。
我希望得到这样的答案
- 指向更多的实现，讨论等
- 对组成理想软件包pipe理器的一组function的冗长描述。
- 一个特定的期望/不期望的特征的描述。 随意从上面详细阐述我的想法。
- 让我惊喜。
从版本控制自动发布
我很乐意看到一个标准的，集中的， 单一的 Emacs包pipe理器。 现在，我把我的钱放在ELPA上 ，但还有很长的路要走。
对于Emacs软件包pipe理器来说，最大的帮助就是发布软件包。 在我看来，我希望看到这种情况发生在像GitHub这样的中央托pipe平台上的git之类的版本控制系统 – 这会使作者很容易发布他们的软件包，并且使其他人回馈。
类似于GitHub（用于）可以很容易地发布RubyGems，我想在Emacs包pipe理器中看到类似的东西。 例如，使用“vX.YZ”标记您的存储库，并让您的elisp善良自动提供给所有人。
使用像GitHub这样受欢迎的后端的附加好处是，您将立即获得大量的曝光，这将有助于推动其成功。
我仍然在学习Emacs，所以我没有机会查看包pipe理器，但是一个很好的function是通知用户，如果包使用它，但不在他们的系统上，那么这个包是可用的。 例如，我想在服务器上编辑一个PHP文件，然后尝试
Mx php-mode 和Emacs是一样的
Mx php-mode [no match]
当它应该是这样的
php-mode available from ftp.gnu.org. install? (y/n)
然后它会为我安装和加载php模式。 那会让我的一天在那里。
我期望的最多的是一切有用的东西，并且运作良好。 这就要求你（或者一个维护者团队）积极地去包装所有的东西，并且做任何涉及到的事情 – 给每个作者发送一个有用的包裹，等等。
例如，Debian（以及它的衍生产品：Ubuntu等）的优点是你可以很快地使用你的系统，而不必在存储库之外安装某些东西，并且它的所有内容都经过了彻底的testing。 包pipe理器的实际function很重要，但是对于托pipe包本身来说是次要的。
易于configuration同步 ：我和许多人一样，在许多不同的计算机和服务器上使用Emacs，其中一些是我自己的，有些则不是。 如果软件包pipe理员有某种我可以从一台电脑转移到另一台电脑的文件， 那么在后一台计算机上，软件包pipe理器会将我的Emacs带入我喜欢的状态 – 所有已安装的软件包和configuration。 结合能够轻松地安装站点范围（如果有根权限）或作为单个用户，我可以在任何地方同步所有的Emacsen。
我几乎肯定的是，最好的解决scheme是向ELPA提交更多的软件包，并为package.el添加多源支持。 Emacs维护人员表示，只要默认指向FSF存储库，他们就会考虑在版本24中包含package.el。
当然，提交也需要是一个自动化的过程。 目前邮寄ELPA维护者的方法只能在小范围内工作。
不pipe怎么做，我认为最重要的是将软件包提交到版本库应该是微不足道的。 同时，我们不希望这些软件包立即可用，以防止恶意代码（以及由于许可问题）。 除非有一个基于encryption签名的“信任”系统。
也很有用：
- “元包”，一次安装几个包。
- 同样，我们应该能够安装一组elisp文件，以便维护
- 不应该允许“破碎的”软件包破坏Emacs的启动。 这很容易，我已经在我自己的.emacs中实现了
- 能够安装脚本以外的文件。 这经常被忽视，但非常有用。 例如，您可以发送图像，图标，工具栏等。
- 版本控制：软件包X需要软件包Y> 1.0
- testing：执行基本的健全性检查，testing冲突（键绑定，函数重定义，预期存在但不存在的函数等）。
- BUG跟踪 ：我不能强调这个足够的重要性。 有一个集中的地方报告包错误（并能够跟踪它们）对于确保包的质量非常重要。
某种forms的压缩存档似乎是最好的做一些上述。
到目前为止，ELPA得到了很大的改进，似乎是一个很好的select。
我曾经花了一些时间为Emacs写一个小包pipe理器。
http://gmarceau.qc.ca/plugin.el
我写了：
插件是我为Emacs创build一个包pipe理器的尝试。 插件会自动下载Emacs扩展，将其解压缩到一个目录中，将该目录添加到加载path，生成自动加载注释以及修改您的dot-emacs文件。 自动加载注释是Emacs鲜为人知的function。 一旦生成了Emacs扩展，就可以快速，增量地加载，如果你有像我一样多的扩展，这真的很不错。
你需要两个库文件才能运行， loop-constructs.el和record.el
我认为iPhone的黑客已经非常接近我想要的东西了，就像Ubuntu的“apt”一样。
我喜欢能够：
- 加
- 删除（只包）
- 删除用户设置
- 查看文档
- 升级（阅读更改日志后）
- 添加新的存档（又名添加存储库）
- 看依赖关系
- 看版本
- search名称，关键字
- 浏览（添加date，修改date，名称）
- 保存所有安装的软件包和设置
- 加载一组软件包和设置
我想要一个主要的东西，所有的工作很好，是做任何事情的推荐方式。 然后是一个全球化的全球性集合，然后任何人都可以托pipe自己的档案。
这将是很好，如果这一切都绑在git / svn /无论如何，以便您可以安装旧版本。 通过分叉等等来制作你自己的补丁。
除了上面提到的，我还期望debian和其他仓库 – 一套稳定，实用，未经testing的软件包。 能够添加我自己的仓库 – 我直接从VCS使用大量的软件包，所以创build我自己的软件包
我认为包pipe理者应该从Rubygems中获得很多灵感。 我也认为它应该有一个像Gemcutter的网站。
中央仓库也可以很好（如Emacsmirror ）。 但是，如果存在收集所有包的Gemcutter这样的站点，则这可能不是必需的。
我认为这些事情对于这个工作很重要。
- 收集所有包裹的某种中央位置
- 易于添加包
- 易于维护包装
- 易于贡献给其他包
- 易于安装，卸载和更新包
- 可以添加包依赖项
- 所有软件包的通用结构
所以像Rubygems这样的包pipe理器，像Gemcutter这样的站点和一个像Emacsmirror这样的中央仓库（最好在Github上，因为它是社交编码）会让Emacs真的很好。
总而言之，我认为应该从Rails中获得很多灵感，Rails如何处理Gems。
我不知道这个问题有多新鲜
但我希望看到的模型是CPAN。 我也不知道Rubygems，但它听起来和CPAN很相似。
CPAN是一个perl归档+图书pipe理系统。 当我需要编写一个需要FTP或SOAP或JSON或XML或ZIP，或…等等的Perl程序时，我可以运行CPAN软件包pipe理器，select必需的软件包进行下载，查看和validation依赖关系，然后安装一切。 CPAN被镜像到“无处不在”。
CPAN对我的目的来说是非常好的，而对于emacs来说，类似的东西是很好的。 它还支持按需构buildC / C ++代码。
这就是我想在emacs中看到的。
进一步评论要求。
- 显式下载软件包。 没有自动安装。 没有无形的下载。 我想要求新的库或新的function。
- 我应该能够列出已安装软件包的名称/版本/时间戳。
- 如果我的朋友把我的名单给我，我应该能够对我的emacs状态进行比较。
- 检查更新function。 哪些更新可用？ 他们修复了什么？
- 依赖性检查，validation和下载。 如果我安装了csharp模式，并且需要cc-mode的v5.0.28，那么它应该和我确认，我还必须下载cc-mode。
- 这些软件包应该有某种社区排名，比如在isohunt上排名。 我想看看一个软件包有3个upvotes或3000个。
- “交易”行为。 如果安装变得繁荣，则必须放松到最后一个已知状态。
- failsafes。 如果我已经在linum.el中join了自定义mod，除非我明确允许，否则它应该拒绝安装一个新的版本来覆盖我的更改。 即使开始之前，它应该警告我。 在checksum / md5上执行现有安装。
- 可以select从压缩档案中运行一些软件包，比如zip文件。 所以我从来没有怀疑，我没有更新任何embedded的elisp。
- 能够使用镜像主机进行软件包分发。
- 所有这些function都应该可以通过Mx library-manageemnt或其他东西来访问。
最后，有一种方法可以分离或组织函数库。 分层名称空间。 Emacs的平面命名空间是非常过时的。 这是独立的，但与包pipe理的核心function是互补的。 我不是一个唇齿相依的大师，所以我不知道这会是多么困难; 也许已经有办法做到这一点。
软件包pipe理员不提供任何我认为具有简单依赖关系的单文件elisp软件包：添加和删除site-lisp从来没有引起任何问题。 它是依靠外部程序（例如，ispell），多文件包（例如，auctex，org模式）的软件包，可能会非常棘手。 无法想象任何具有非平凡依赖关系的单文件elisp软件包。
对于这些缺乏包pipe理器的人来说，我希望emacs的elisp-packages能够获得可以集中运行的testing套件，并在依赖性失败的情况下提供有用的信息。
