Фон

Я использую emacs ежедневно, но в основном, чтобы добиться цели. Мне не очень нравится настраивать его больше, чем добавлять пакеты, и мне не нравится устранять неполадки. Я хочу, чтобы emacs отошел на второй план, как это делает хорошая ОС, и просто продолжил. Некоторое время назад я обнаружил, что это el-getпозволяет мне устанавливать нужные мне пакеты, которые недоступны, package.elа также дает мне больше контроля, например, выбирает maintветку Org-mode, а не тупик, который может вызвать временные проблемы. Теперь я не уверен, должен ли я использовать el-getили нет.

Вопрос

el-getКазалось бы, отличное решение для различных репозиториев и Emacs хаков там. Он предлагал возможности, которые были просто невозможны package.el. Теперь, когда package.elв более новых версиях emacs ( >=24.4) поддерживается несколько репозиториев, каковы варианты использования el-getи аналогичные альтернативы встроенному в emacs диспетчеру пакетов?

Есть вещи, которые все еще невозможны с 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загружает непрозрачные архивы с центральных серверов без возможности выбора конкретной версии пакета и не позволяет вам вносить локальные изменения в ваши пакеты; внести изменения вверх по течению невозможно. straight.elклонирует Git-репозитории децентрализованным способом (но он автоматически использует рецепты из MELPA , GNU ELPA и EmacsMirror , если хотите) и позволяет вам вносить в них произвольные локальные изменения, фиксировать эти изменения и вносить вклад в последующий поток . Это можно сделать вручную или использовать встроенные операции управления массовыми репозиториями. Изменения в ваших пакетах обнаруживаются автоматически, и ручная перестройка не требуется. Более того,straight.el поддерживает полную воспроизводимость для вашей конфигурации Emacs, поскольку позволяет вам написать файл блокировки редакции, который включает в себя Git-хэши всех ваших пакетов.
• Quelpa и Cask основаны на одних и package.elтех же недостатках и наследуют их. Например, Cask не имеет никакой концепции установки конкретной версии пакета. Quelpa делает, но требует, чтобы вы жестко закодировали хеш Git в свой файл инициализации. полностью straight.elизбегая package.el, заменяя все его основные функциональные возможности унифицированным дизайном, приспособленным ко многим другим случаям использования.
• Преимущество el-get в том, что вы можете устанавливать пакеты абсолютно везде (все известные системы контроля версий, произвольный HTTP, системные менеджеры пакетов, EmacsWiki, даже go get!?). Однако, поддерживая так много источников, el-get не может обеспечить такие расширенные операции управления пакетами (такие как воспроизводимость с помощью файлов ревизий и интерактивные операции управления репозиториями) straight.el. straight.elподдерживает только Git, так как большинство пакетов доступно через Git, а те, которые не могут быть получены через EmacsMirror (я осмелюсь найти тот, который не может быть!). Обратите внимание, что straight.elтем не менее предоставляет расширяемый API для дополнительных бэкэндов управления версиями (например, для Mercurial), которые будут добавлены в будущем, если это необходимо.
• Борг имеет очень похожую философию straight.elи дает много таких же преимуществ. Тем не менее, он не предназначен , чтобы быть полным менеджер пакетов, и предназначен для использования в концерне с другими инструментами , такими как epkg, auto-compileи Magit. Напротив, straight.elон самодостаточен и обеспечивает все необходимое самостоятельно, практически не требуя дополнительной настройки. Кроме того, Borg использует подмодули Git, интерфейс которых имеет некоторые острые углы, тогда как straight.elиспользует независимо управляемые репозитории Git, обеспечивая дополнительную гибкость и мощь.
• Есть также ручной подход, но я не рекомендую это. Через пару месяцев вы бы заново изобрели Борг. Затем, через пару месяцев, вы бы заново изобрели straight.el. Вы узнаете много нового об управлении пакетами;)

Несмотря на то, что есть плюсы и минусы, я думаю, что el-get по-прежнему актуален, несмотря на твердое мнение @lunaryon (тоже reepep).

Некоторое время я использовал raw package.el с use-package (от 2 до 3 лет), затем переключился на el-get , затем Cask . Я вернулся в Эль-Гет несколько дней назад. До этого package.el , как и многие другие, я вручную обрабатывал надстройками.

Почему я вернулся в Эль-Гет ? Я столкнулся с некоторой странностью Cask по поводу того, что что-то не является git-репо (мой пакет Github, которого нет в MELPA), в то время как этот пакет на самом деле использует git ... Я не потрудился исследовать или создать тикет, просто вытащил свой старый Конфигурация el-get, и я был хорош, чтобы пойти в кратчайшие сроки.

Несколько вещей, которые мне нравятся в el-get :

• Он поддерживает несколько сборщиков, а не только git.
• Содержит достаточно предопределенных рецептов
• Быстрее, чем бочка при запуске.
• и да @lunaryorn, Wiki - это не место для распространения кода, но я не хочу создавать репозиторий Github, если на emacsmirror (Github) нет клона .
• Самостоятельно, с Cask вам нужна внешняя установка. Я использую один файл инициализации (не модульная конфигурация) с allout-mode для навигации по разделам.
• el-get достаточно прост с точки зрения пользователя.

Примечание: я использую Emacs Git HEAD под OSX и Linux.

Возможно, вы захотите взглянуть на paradox. Это не другой менеджер пакетов, а аккуратный интерфейс для package.el. Например, когда вы обновляете пакеты, он спрашивает, хотите ли вы установить их и удалить старые за один шаг.

Если вы используете его, вы, вероятно, захотите установить paradox-execute-asynchronouslyего tв файле инициализации.