使用package.el进行安装和更新,但使用package进行加载和配置


15

在最近了解了有关信息之后,use-package我决定将配置移植到该配置中,但发现自己不愿意放弃使用package.el安装软件包并保持更新的便利。我发现将use-package和结合起来有点棘手package.el

我通常对学习人们如何use-packagepackage.el系统结合感兴趣,但是对于更具体的问题,请继续阅读。

这就是我想要的:

  1. 要由软件包管理器安装软件包,以便我可以轻松浏览软件包并通过进行更新list-packages
  2. 要通过专门配置和加载程序包use-package,因此我可以轻松地在init文件中准确查看正在加载的内容以及配置方式。
  3. (可选)我也希望能够通过use-package:ensure关键字安装软件包。

如果我正确理解的话,我几乎package-initialize不需要做什么,基本上只希望它设置的方式load-path。目前,我的配置中包含以下内容:

;(package-initialize)
(setq package-enable-at-startup nil)
(let ((default-directory "~/.emacs.d/elpa"))
  (normal-top-level-add-subdirs-to-load-path))
(require 'use-package)

第一行带有注释,因此Emacs 25不会(package-initialize)对我的init文件添加帮助。有位normal-top-level-add-subdirs-to-load-path是一种近似什么package-initialize会使load-path,这似乎是足够好的近似。

这似乎实现了我的愿望1和2,但没有达到3。如果尝试使用:ensure,则会收到一条错误消息,指出package.el未初始化。调用package-initialize可以解决该问题,但是我希望避免这种情况,因为a)我不想加载所有无数的自动加载程序(我更喜欢使用它use-package来精确创建所需的自动加载程序),以及b)我希望能够轻松避免在需要时加载某些已安装的软件包(使用即可轻松完成use-package)。

有没有人建议如何做?

Answers:


11

IIUC您想做的是:

(package-initialize t)

请注意该t参数,这是您获得幸福的关键,因为它将(或至少应该)初始化package.el而不激活所有已安装的软件包。


1
这回答了我的问题,即使现在我倾向于使用package-initialize它来解决我的问题。
奥马尔

15

使用当前配置,您已经有效地禁用了 package.el,因为您没有初始化软件包管理器并阻止了Emacs自动对其进行初始化。作为回报,您要做load-path的只是将ELPA添加到中,但这只是package.el的一小部分。我不确定为什么要这样做,但这不是我建议的设置。

具体来说,您不会通过方法自动加载程序包,这意味着最初没有任何程序包中的命令可用。

换句话说,M-x只会为您提供内置命令。为了从你的包命令添加你必须明确添加:commands定义,所有use-package声明,这相当于一个不少,尤其是努力维护的大型软件包,如Magit换基本上为零增益package.el给你自动加载免费。


use-package与package.el 结合实际上非常简单-整个设置都基于这种结合-但让package.el实际上发挥作用要好得多。只需在初始文件的开头初始化package.el:

(require 'package)
(setq package-enable-at-startup nil)   ; To prevent initialising twice
(add-to-list 'package-archives '("melpa" . "https://stable.melpa.org/packages/"))

(package-initialize)

为了方便起见,您随后可能想要bootstrap use-package(如果尚未安装):

(unless (package-installed-p 'use-package)
  (package-refresh-contents)
  (package-install 'use-package))

这样,您就可以在新系统上启动Emacs会话,并且init.el将自动安装use-package

最终,您需要加载use-package

(eval-when-compile
  (require 'use-package))

现在,您可以use-package用来安装和配置软件包:

(use-package magit                      ; The one and only Git frontend
  :ensure t
  :bind (("C-c v c" . magit-clone)
         ("C-c v v" . magit-status)
         ("C-c v g" . magit-blame)
         ("C-c v l" . magit-log-buffer-file)
         ("C-c v p" . magit-pull))
   :config (setq magit-save-repository-buffers 'dontask))

当Emacs现在在启动期间评估此表单时,use-package将检查Magit是否已安装,并在必要时自动安装。


3
“我不确定为什么要这么做”:我看到的唯一原因是有关启动时间:package-initialize需要一些时间来填充路径,定义自动加载并完成其余工作。我想我在某处读到Jon Wiegley本人(的作者use-package)更喜欢在use-package节中声明所有自动加载的命令,而不是依赖于package.el
弗朗索瓦·佛伏特

上次我看他根本不使用package.el,无论如何,我认为您不会收获很多。load-path无论是通过use-package还是通过,都需要填充并添加自动加载package.el。我怀疑是否存在可测量的差异,特别是如果您拥有具有快速磁盘的现代系统。
lunaryorn

3
同意 我自己做了时间。使用快速磁盘,您实际上看不出太大的区别。如果使用慢速磁盘,则启动速度可能会package-initialize比中的自定义列表慢得多(大约0.2秒)load-path。我将此归因于这样做的文件系统的“探索” package.el。但是,我从未测量过从autoload文件加载定义和将它们放入use-package节之间的性能差异。
弗朗索瓦·佛沃特

好吧,我不会说我已经禁用package.el系统,我只会说我只是禁用了package-initialize!原因是,虽然我喜欢list-packages浏览新的软件包,特别是要更新当前安装的所有软件包,但我认为我倾向于有针对性地加载use-package。对我来说,仅对命令自动加载对我来说听起来不错!
奥马尔

1
@OmarAntolín-Camarena为什么不呢?自动加载本质上是面向用户的程序包的公共接口,并且由于package.el成为分发程序包的标准方式,因此我们可以依靠它们的存在。
lunaryorn
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.