Використання package.el для встановлення та оновлення, але use-package для завантаження та налаштування


15

Нещодавно дізнавшись про це, use-packageя вирішив передати свою конфігурацію до неї, але виявив неохоче відмовлятися від зручності використання package.elдля встановлення пакетів та постійно оновлювати їх. Я вважаю трохи складно поєднувати use-packageі package.el.

Мені взагалі цікаво дізнатися, як люди поєднуються use-packageз package.elсистемою, але для конкретнішого питання продовжуйте читати.

Ось що я хочу:

  1. Щоб встановити пакунки менеджером пакунків, щоб я міг легко переглядати пакунки та постійно оновлювати їх list-packages.
  2. Налаштовувати та завантажувати пакунки виключно через use-package, тому я можу легко бачити у своєму файлі init, що саме я завантажую та як він налаштований.
  3. За бажанням, я хотів би також мати можливість встановити пакети через use-package«s :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би це виправити, але я хочу цього уникнути, оскільки а) я не хочу завантажувати всі безлічі автозавантажень (я вважаю за краще використовувати use-packageдля створення саме потрібних автозавантажень), і б) я хочу легко уникати завантаження певних встановлених пакетів, коли я хочу (що легко зробити use-package).

Хтось має рекомендацію, як це зробити?

Відповіді:


11

МІКУ, що ви хочете зробити, це:

(package-initialize t)

Зверніть увагу на tаргумент, який є ключовим для вашого щастя тут, оскільки він (або повинен принаймні) ініціалізувати package.el, не активуючи всі встановлені пакети.


1
Це відповідає на моє запитання, хоча зараз я схиляюся до використання, package-initializeщо робить моє запитання суперечливим.
Омар

15

За допомогою вашої поточної конфігурації ви фактично відключили package.el, оскільки ви не ініціалізуєте менеджер пакунків і не дозволяєте Emacs автоматично ініціалізувати його. Все, що ви робите натомість, - це додати ELPA до load-path, але це лише невеликий набір того, що робить package.el. Я не впевнений, чому ви це робите, але я б не рекомендував налаштування.

Зокрема, ви не отримаєте автоматичне завантаження пакунків із своїм підходом, а це означає, що спочатку ніякі команди з будь-якого пакету не будуть доступні.

Іншими словами, M-xзапропонує вам лише вбудовані команди. Щоб додати команди з ваших пакетів, вам доведеться додати чіткі :commandsвизначення до всіх своїх use-packageдекларацій, що становить великі зусилля з обслуговування - особливо для великих пакетів, таких як Magit - для фактично нульового посилення. Package.el дає вам автозавантаження безкоштовно .


Поєднання use-packageз package.el насправді дуже просте - y вся настройка заснована на цій комбінації - але набагато краще дозволити package.el насправді виконати свою роботу. Просто ініціалізуйте package.el на самому початку вашого файлу init:

(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)

Для зручності згодом ви можете скористатися завантажувальним інструментом 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потрібно деякий час, щоб заповнити шлях, визначити автоматичне завантаження та виконати решту його матеріалів. Думаю, я десь прочитав, що сам Джон Віглі (автор use-package) вважає за краще оголошувати всі автоматично завантажені команди в use-packageстрофах, а не покладатися на них package.el.
Франсуа Февотте

Минулого разу я дивився, що він взагалі не використовував package.el, і в будь-якому випадку, я не думаю, що ти багато заробиш. Потрібно заповнити load-pathта додати автозавантаження в будь-якому випадку, через use-packageабо через package.el. Я сумніваюся, що є вимірна різниця, особливо якщо у вас сучасна система зі швидким диском.
місячник 20

3
Домовились. Я робив таймінги сам. За допомогою швидкого диска ви практично не бачите різниці. На повільному диску запуск може бути помітно повільнішим (щось на зразок 0,2 с), package-initializeніж у власному списку в load-path. Я приписую це "дослідженню" файлової системи, яка package.elце робить. Однак я ніколи не вимірював суттєвої різниці в продуктивності між завантаженням autoloadвизначень з файлів і наявністю їх у use-packageстрофах.
Франсуа Февотте

Ну, я б не сказав , я відключив в package.elсистему, я б сказав , що я тільки інвалід package-initialize! Причина в тому, що, хоча мені подобається list-packagesпереглядати нові пакети та спеціально оновлювати всі мої встановлені пакети, я думаю, що я вважаю за краще цільове завантаження use-package. Для мене, що має автоматичне завантаження лише для команд, я використовую звуки як добру річ!
Омар

1
@ OmarAntolín-Camarena Чому ні? Автозавантаження по суті є загальнодоступним інтерфейсом пакету, орієнтованого на користувачів, і оскільки package.el став стандартним способом розповсюдження пакетів, ми можемо розраховувати на їх наявність.
місячний рік
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.