Каковы варианты использования альтернативных менеджеров пакетов по сравнению с `package.el`?


14

Фон

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

Вопрос

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


2
Смотрите также: quelpa . Краткий ответ: конечно, есть пакеты, которых нет в ELPA / MELPA / Marmalade. Если вы обнаружите, что он вам нужен, вы все равно можете получить его без ужасных взломов el-getи тому подобного.
PythonNut

Ответы:


8

Есть вещи, которые все еще невозможны с ELPA, и есть вещи, которые всегда будут невозможны с ELPA, потому что они не вписываются в концепцию ELPA: вы никогда не сможете установить конкретный коммит по его хешу из разветвленного репозиторий. Кроме того, вы никогда не сможете применять локальные патчи к пакету до его установки. Эти функции просто выходят за рамки ELPA, и если вам они нужны, вам придется использовать альтернативный менеджер пакетов.

Я думаю, однако, что el-get является своего рода устаревшим решением в наше время. Учитывая, что ELPA стала де-факто стандартным менеджером пакетов для Emacs, альтернативные менеджеры пакетов должны легко интегрироваться с ELPA. Однако el-get не предоставляет свои собственные пакеты для ELPA, а это означает, что его пакеты полностью невидимы для ELPA, а пакеты ELPA никогда не могут зависеть от пакетов el-get, что имеет очевидные последствия для управления зависимостями.

Если вам нужны функции, выходящие за рамки ELPA, вам стоит взглянуть на QUELPA, а не на el-get.


«Если бы они этого не сделали, никто бы не стал их поддерживать». Однако целью может быть только эго разработчика.
Т. Веррон

Однако это могучее эго могло бы легко привлечь такое большое сообщество, какое еще имеет el-get, и QUELPA быстро приобрели :)
lunaryorn

Я вообще комментировал, конечно. ;)Что касается специфики имеющихся пакетов, ваш ответ, помимо формулировки здравого смысла, имеет большое значение, демонстрируя цели el-get и quelpa.
Т. Веррон

@ Т. Веррон Да, точка взята. Я удалил это заявление, это было глупо. Сожалею.
lunaryorn

@lunaryorn с el-get, however, does not expose its own packages to ELPA, meaning that **its packages** are entirely invisible to ELPA and ELPA тобой имеет в виду вещи, установленные el-get, верно?
toogley

6

Я написал новый менеджер пакетов для 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. Вы узнаете много нового об управлении пакетами;)

4

Несмотря на то, что есть плюсы и минусы, я думаю, что 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.


Мне жаль, что у вас были проблемы с Каском, но я не думаю, что ваши личные проблемы и ваше явное разочарование в Каске имеют какое-либо отношение к этому вопросу. В частности, Cask является интерфейсом ELPA с очень узкой областью применения (главным образом, разработкой пакетов). Хотя вы можете использовать его и для управления пакетами, он концептуально ортогонален el-get.
lunaryorn

Другими словами, Cask не заменяет el-get и не стремится к этому. Это совершенно не связано. ELPA заменяет el-get. Лучший выбор для установок на основе Git - это не el-get, это QUELPA, и, как я уже сказал в своем ответе, это веская причина для использования QUELPA.
lunaryorn

1
Я согласен с узким кругом Бочки, не поймите меня неправильно. Несмотря на мои "проблемы" с Cask, я все еще использую его на некоторых машинах Linux. У меня также нет пакетов "git-only", некоторые из них находятся в Mercurial или других системах контроля версий. Я также использую пакеты от других людей, которые, вероятно, никогда не будут в MELPA или git-репозитории. Единственное, что я хочу сказать, это то, что el-get все еще в порядке, когда MELPA не содержит всех пакетов, необходимых кому-то. Хотя я знаю о QUELPA, el-get для меня достаточно хорош.
Римеро

Понимаете, и я хочу сказать, что в настоящее время el-get больше не подходит, потому что он обходит встроенное управление зависимостями ELPA и Emacs, рискуя поломкой и установкой дублированных пакетов. QUELPA предоставляет те же функции, что и el-get, но не имеет этого недостатка. Это просто лучше в наше время.
lunaryorn

@rimero У меня был точно такой же опыт. Кроме того, я только что попробовал Quelpa несколько дней назад, и мне пришлось отказаться от него, по крайней мере, на данный момент. El-get кажется еще более гибким, мощным и в целом более быстрым, по крайней мере, для моего варианта использования. Я считаю, что они охватывают две совершенно разные точки зрения, поэтому это также может зависеть от того, какой пользователь Emacs один. Было бы целесообразно попробовать оба, прежде чем совершить один или другой.
GSL

1

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.