Answers:
GNU ELPA是官方的GNU Emacs软件包存储库。它是默认情况下唯一启用的功能,这意味着它的作用范围最大。同时,提交软件包存在一些麻烦,需要FSF版权分配,这意味着软件包选择相对有限。
MELPA和Marmalade都是第三方软件包存储库。它们没有得到GNU的正式支持,但是还有更多的软件包选择。包装质量的可变性更高,但您更有可能找到想要的东西,尤其是当它有点晦涩时。
果酱和MELPA的包裹上传者模型略有不同。我的理解是,MELPA直接(即通过GitHub)跟踪版本控制存储库,让软件包作者只需将提交推送到分支即可更新软件包。另一方面,果酱(Marmalade)则让人们将软件包明确上传到存储库。
在实践中,我还没有看到MELPA和果酱之间的区别。使它们都具有尽可能多的可安装软件包选择没有太多弊端:我一直在使用这两者(当然还有GNU ELPA)已经有一段时间了,并且没有任何重大问题。
使两个存储库都启用(我没有遇到自己)的一个可能的问题(我还没有遇到我自己),是在这两个版本中都有可用的软件包。默认情况下,程序包管理器(package.el
)无法解决这种冲突。但是,您可以通过安装melpa
软件包来解决此问题,该软件包可让您自定义哪些存储库中提供或不提供哪些软件包。您可以在此处或从melpa
软件包的文档中查看更多详细信息。
正如@Malabarba有用地指出的那样,此问题已在Emacs 24.4中解决。
如果您真的担心安全性,则可以避免同时使用MELPA和Marmalade,因为它们允许任何人上传软件包,并且据我所知,没有任何主动的安全性安排。另一方面,GNU ELPA存储库由FSF管理,并已签名了应该有用的软件包。当然,如果安全性非常重要,您可能只想手工查看并安装elisp软件包,而不要使用软件包管理器。
按照我的想法,某些仓库比其他仓库有更多的包提交开销。具有更多开销的存储库往往具有较少的软件包。从最大到最小开销的顺序:
我个人认为,从长远来看,对于大多数用户而言,MELPA稳定版或果酱都可能会取胜-MELPA固有的特性非常不稳定,ELPA的限制性太强,无法真正扩展到许多软件包。但这只是一个意见。
有几个可用的软件包存储库。
官方
GNU ELPA是官方的软件包回购。它很小,并且需要(所有软件包作者)版权分配给FSF才能做出贡献。
GNU ELPA上的软件包实际上只是一个git repo。在此托管的好处是,如果Emacs本身添加或不赞成使用功能,则核心团队将尝试更新软件包。
从源构建
MELPA是最大,增长最快的软件包仓库。每次将新版本推送到存储库或更新EmacsWiki页面时,它都会发布新版本。
这是最前沿的,但是在实践中效果很好。策划MELPA是为了避免重复包装,并确保记录包装的规范位置(而不是随机分叉)。
MELPA确实存在版本只是时间戳的问题,例如my-package-20131231.2359
。这意味着如果您依赖我的包装:
;; Package-Requires: ((my-package "1.2.3"))
那么Emacs会认为MELPA上的任何版本都是新的。
MELPA Stable与MELPA相同,但不是使用datestamp版本,而是使用git标签中的版本。这样可以更好地解决依赖关系,但是在依赖Wiki包方面存在问题。
用户上传
Marmalade更像是来自其他编程语言的传统存储库。程序包开发人员在发布时将程序包上传到Marmalade。
原则上,这使软件包具有适当的发布过程(Marmalade早于MELPA稳定),并且还避免了自动生成的版本号问题。但是,没有身份验证。任何人都可以上传软件包,即使他们没有写。如果的维护者my-package
发现其他人已上传my-package
并且随后无法上传新版本,则这将变得困难。
Marmalade曾经是一个node.js应用程序,现在是用elisp编写的。两种版本偶尔都有正常运行时间问题。
特定项目
组织模式ELPA是仅托管org
和的存储库org-plus-contrib
。组织模式是Emacs核心的一部分,但它是外部开发的,并且代码仅与Emacs干线定期同步。这个仓库让您拥有最前沿的组织模式。
User42 ELPA是单个软件包开发人员的回购协议,该软件包开发人员已经发布了许多Emacs软件包。如果您喜欢他的任何软件包,则可以添加此仓库。
Sunrise Commander ELPA是Sunrise Commander(受午夜指挥官启发的Emacs文件浏览软件包)扩展库。
退休的
Tromey的ELPA是第一个存储库。正式将其替换为GNU ELPA,但没有相同的版权分配要求。自2010年起,不再更新。
Elpy软件包归档文件包含Jorgen Schaefer为“ Elpy,Emacs Python开发环境”开发的各种软件包,但已迁移到MELPA Stable。
no one has mentioned the risks involved in using github, a commercial provider of web based software, as a backend
:但我敢肯定,现在是Microsoft GitHub ;-)
一些其他信息,以补充此处的其他答案。
有关MELPA和MELPA“稳定”的一些信息-
首先查看来自StackOverflow的这个非常重复的问题,包括问题本身的注释。特别是,在与唐纳德·柯蒂斯(唐纳德·柯蒂斯(MELPA和MELPA马stable的维护者))交换电子邮件后,我发表的以下评论:
从他的观点 [唐纳德·柯蒂斯(Donald Curtis),据我了解他与我的来信 ] 来看,“稳定”的MELPA网站仅处于维护模式。而且,像我的代码这样的代码不存在的唯一原因是,没有人实现从“稳定”站点的Wiki [Emacs Wiki] 上载。而且,任何人都不会进行“策划”-没有进行过滤以确定软件包是否稳定,有风险等。某些软件包开发人员要求存在两个站点,这些站点希望将其开发版本与较旧的版本(“稳定的”)区分开来。 “)版本。
总之,“ MELPA稳定”中的内容本质上没有哪个“稳定”的。版本编号和提要方法可以不同;就这样。并且,如果特定的软件包维护者想要将“稳定”版本与“开发”版本区分开,并希望通过将它们上传到两个不同的站点来做到这一点,那么效果就是该软件包。
MELPA与Marmalade(和GNU ELPA)之间的区别是,不需要从git存储库中获取对MELPA贡献的代码。特别是,它可以自动从Emacs Wiki的Elisp Area中拉出。
就像有人说的那样,这是否意味着任何人都可以上传任何东西,而您却无法知道该代码是否实际上是所声明的作者等。是的,没有。通常,是的:任何人都可以自由地将Elisp代码上传到Emacs Wiki。如Elisp-Area页面顶部所示:
这是EmacsWiki elisp区域,我们在其中收集EmacsLisp文件。不需要登录,不需要版本控制,不需要ftp,不需要密码。它与Wiki本身一样简单。这也意味着任何人都可以在这些EmacsLisp文件中放置恶意代码。如有疑问,请勿使用。
但是,您知道,我是Wiki的管理员,而我在Wiki Elisp Area中自己的Lisp库是锁定页面。这意味着只有Wiki管理员可以上传它们。因此,在这种情况下,您可以确定我从MELPA或Emacs Wiki下载的我的库是我上传的。但是,与Internet上的所有内容一样,没有铁定的保证,就像代码本身没有保证一样。正如每个GPL库中的GPL内容所说:
分发该程序是希望它会有用,但是没有任何担保;甚至没有对适销性或特定用途适用性的暗示保证。有关更多详细信息,请参见GNU通用公共许可证。
HTH。骇客入侵。