Каковы практические различия между различными репозиториями пакетов Emacs?


124

Я заметил, что есть несколько разных репозиториев, которые часто содержат одно и то же программное обеспечение. Почему я хотел бы предпочесть:

  • GNU ELPA
  • конфитюр
  • MELPA

над остальными? Поскольку ни один репозиторий не содержит всех пакетов, которые мне нужны, целесообразно ли включать эти репозитории одновременно?

Ответы:


82

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

MELPA и Marmalade являются сторонними хранилищами пакетов. Они официально не поддерживаются GNU, но также имеют гораздо больший выбор пакетов. Качество упаковки немного более изменчиво, но вы с большей вероятностью найдете то, что ищете, особенно если это немного неясно.

Marmalade и MELPA имеют несколько разные модели для загрузчиков пакетов. Насколько я понимаю, MELPA отслеживает хранилище управления версиями напрямую (например, через GitHub), позволяя авторам пакетов обновлять пакеты, просто отправляя коммиты в ветку. Мармелад, с другой стороны, заставляет людей явно загружать пакеты в хранилище.

На практике я не видел большой разницы между MELPA и Мармеладом. Нет большого недостатка в том, чтобы предоставить им обоим максимально широкий выбор устанавливаемых пакетов: я использовал оба (и GNU ELPA, конечно) какое-то время без особых проблем.

Одной из возможных проблем (с которой я не сталкивался) с включением обоих репозиториев, с которой я не сталкивался, является наличие пакетов, доступных в обеих версиях. По умолчанию менеджер пакетов ( package.el) не имеет способа разрешить конфликт, подобный этому; однако, вы можете решить эту проблему, установив melpaпакет, который позволяет вам настраивать, какие пакеты предоставляются или исключаются из каких репозиториев. Вы можете увидеть более подробную информацию здесь или из документации для melpaпакета.

Как подсказал @Malabarba, эта проблема решена в Emacs 24.4.

Если вы действительно беспокоитесь о безопасности, вы можете избегать как MELPA, так и Marmalade, потому что они позволяют кому-либо загружать пакеты и, насколько я знаю, не имеют никаких активных мер безопасности. Хранилище GNU ELPA, с другой стороны, управляется FSF и имеет подписанные пакеты, которые должны помочь. Конечно, если безопасность действительно важна, вы можете просто просмотреть и установить пакеты elisp вручную вместо использования менеджера пакетов.


13
Новый package.el, который входит в emacs 24.4, корректно обрабатывает расходящиеся номера версий. Если два репозитория имеют один и тот же пакет с разной версией, вам предлагаются оба варианта, и одно никогда не переопределит другое во время обновления.
Малабарба

1
@Malabarba: Вау, это приятно слышать!
Тихон Джелвис

14
Это хороший ответ, но, вероятно, следует также упомянуть MELPA stable ( melpa-stable.milkbox.net ). MELPA автоматически получит последнюю ревизию из главной ветки репозитория, а MELPA stable получит последнюю помеченную ревизию.
Шости

@Shosti: О, аккуратно, я не знал об этом. Возможно, было бы неплохо представить это как свой собственный ответ.
Тихон Джелвис

7
мармелад не позволяет никому загружать пакеты. только зарегистрированные пользователи. Я знаю всех загрузчиков прямо сейчас. Так что есть какая-то рецензия.
Nic Ferrier

44

На мой взгляд, у некоторых репозиториев больше затрат на отправку пакетов, чем у других; в репо с большими накладными расходами, как правило, меньше пакетов. В порядке от большинства к минимуму накладных расходов:

  1. GNU ELPA требует, чтобы весь код был под GPL и авторские права были переданы FSF. Код ELPA по сути «принадлежит» основной команде Emacs, поэтому его гораздо меньше, чем в других репозиториях. (У org-mode есть собственный репо, но тот же режим работы.)
  2. Marmalade требует, чтобы весь код имел лицензию, совместимую с GPL, и все пакеты загружаются вручную. Право собственности немного не определено, и смена владельца не имеет установленного процесса AFAIK.
  3. MELPA Stable более или менее напрямую конкурирует с Marmalade, за исключением того, что не имеет лицензионных ограничений и автоматически собирает пакеты из репозиториев git, используя последнюю помеченную ревизию. Право собственности определяется через репозиторий MELPA (смена владельца происходит по запросу извлечения).
  4. MELPA похожа на стабильную версию MELPA, за исключением того, что она всегда работает с последней ревизии в основной ветке git-репо. Пакеты, как правило, являются «передовыми», и это может быть чем-то вроде общей для всех стабильности (что имеет свои плюсы и минусы).

Лично я думаю, что MELPA Stable или Marmalade, вероятно, выиграют в долгосрочной перспективе для большинства пользователей - собственно MELPA довольно нестабильна, а ELPA слишком ограничена, чтобы быть действительно масштабируемой для большого количества пакетов. Но это просто мнение.


6
У marmalade теперь есть API для добавления владельцев в пакеты.
Nic Ferrier

31

Доступно несколько репозиториев пакетов.

официальный

GNU ELPA является официальным пакетом репо. Он небольшой и требует передачи авторских прав (всех авторов пакета) в ФФС, чтобы способствовать этому.

Пакеты на GNU ELPA на самом деле просто git-репо . Преимущество размещения здесь состоит в том, что основная команда пытается обновить пакеты, если Emacs сам добавляет или осуждает функции.

Построен из источника

MELPA является крупнейшим и наиболее быстро растущим репо-пакетом. Он выпускает новую версию каждый раз, когда новая версия помещается в репозиторий или обновляется страница EmacsWiki.

Это кровоточит, но на практике работает очень хорошо. MELPA курируется, чтобы избежать дублирования пакетов и обеспечить запись канонического дома пакета (вместо случайного разветвления).

У MELPA действительно есть проблема, что версии - это просто временные метки, например my-package-20131231.2359. Это означает, что если вы зависите от my-package:

;; Package-Requires: ((my-package "1.2.3"))

тогда Emacs будет думать, что любая версия на MELPA достаточно новая.

MELPA Stable - это то же самое, что и MELPA, но вместо того, чтобы использовать версии с датой, он использует версии в тегах git. Это позволяет лучше разрешать зависимости, но имеет проблемы с зависимостью от пакетов вики .

Пользователь загружает

Мармелад гораздо больше похож на традиционный репозиторий из других языков программирования. Разработчик пакета загружает пакет в Marmalade, когда они делают релиз.

В принципе, это дает пакетам надлежащий процесс выпуска (Marmalade предшествует стабильной версии MELPA), а также позволяет избежать проблемы с автоматически генерируемым номером версии. Тем не менее, нет подтверждения личности. Любой может загрузить пакет, даже если он его не написал. Это становится трудным, если сопровождающий my-packageобнаруживает, что кто-то еще загрузил его, my-packageи не может впоследствии загрузить новые версии.

Marmalade раньше был приложением node.js, и теперь оно написано на elisp. Обе версии иногда имели проблемы с работоспособностью.

Проект конкретных

Орг-режим ELPA - это репозиторий , в котором только хосты orgи org-plus-contrib. Режим Org является частью ядра Emacs, но он разрабатывается извне, и код периодически синхронизируется с транком Emacs. Этот репо позволяет вам использовать передовой режим орг.

User42 ELPA - это репозиторий для разработчика одного пакета, который выпустил целый ряд пакетов Emacs . Если вам нравится какой-либо из его пакетов, вы можете добавить этот репозиторий.

Sunrise Commander ELPA - это репозиторий для расширений для Sunrise Commander (пакет Emacs для просмотра файлов, созданный по мотивам Midnight Commander ).

На пенсии

ELPA Тромея был первым репо. Он официально заменен GNU ELPA, но у него не было тех же требований по передаче авторских прав. По состоянию на 2010 он больше не обновляется.

Архив пакетов Elpy содержал различные пакеты, разработанные Йоргеном Шефером для «Elpy, среды разработки Emacs Python» , но переведенные в MELPA Stable.


4
У мармелада определенно были проблемы с работоспособностью ... Я думаю, что я решил их с помощью nic.ferrier.me.uk/blog/2014_08/deploying-blue-green-with-docker - никто не упомянул о рисках, связанных с использованием github коммерческий поставщик программного обеспечения на основе веб-технологий в качестве бэкэнда; Я считаю, что это риск. Marmalade - это бесплатное программное обеспечение, и даже встроенная программа может быть установлена ​​кем-то другим.
Nic Ferrier

no one has mentioned the risks involved in using github, a commercial provider of web based software, as a backend: но я уверен, что эти проблемы исчезнут теперь, когда это Microsoft GitHub ;-)
TomRoche

13

Некоторая дополнительная информация, чтобы дополнить другие ответы здесь.

  1. Некоторая информация о MELPA и MELPA "стабильный" -

    Начните с рассмотрения этого довольно повторяющегося вопроса от StackOverflow, включая комментарии к самому вопросу. В частности, этот комментарий, который я разместил после обмена электронной почтой с Дональдом Кертисом (сопровождающим MELPA и MELPA stable):

    С его точки зрения [Дональда Кертиса, и, насколько я понимаю, его общение со мной], «стабильный» сайт MELPA находится только в режиме обслуживания . И единственная причина, по которой такой код не похож на мой, заключается в том, что никто не реализовал загрузку из вики [Emacs Wiki] для «стабильного» сайта. Кроме того, никем не выполняется «кураторство» - нет фильтрации, чтобы определить, является ли пакет стабильным, рискованным и т. Д. Некоторые разработчики пакетов запрашивали существование двух сайтов, которые хотели отличить dev-версии своих пакетов от более старых («стабильных»). ") версии.

    В целом, нет ничего более стабильного в содержании «MELPA stable» . Нумерация версий и метод подачи могут отличаться; вот и все. И если конкретный сопровождающий пакета хочет отличить «стабильные» от «разработанных» версий и хочет сделать это, загрузив их на два разных сайта, то это эффект - для этого пакета .

  2. Одно из различий между MELPA и Marmalade (и GNU ELPA) заключается в том, что не требуется, чтобы код, внесенный в MELPA, был получен из репозитория git. В частности, его можно автоматически вытащить из области Elisp в Emacs Wiki .

    Означает ли это, как говорили некоторые, что любой может загрузить что угодно, и у вас нет возможности узнать, действительно ли код принадлежит заявленному автору и т. Д.? И да и нет. В общем, да: любой может загрузить код Elisp в Emacs Wiki. В верхней части страницы Elisp-Area говорится:

    Это область elisp EmacsWiki, где мы собираем файлы EmacsLisp. Вход в систему не требуется, контроль версий не требуется, FTP не требуется, пароль не требуется. Это так же просто, как сама вики. Это также означает, что любой может поместить вредоносный код в эти файлы EmacsLisp. Если сомневаетесь, не используйте их.

    Однако, как вы знаете, я администратор вики, и мои собственные библиотеки Lisp в вики Elisp Area являются заблокированными страницами. Это означает, что только администратор вики может загрузить их. Так что в этом случае вы можете быть совершенно уверены, что мои библиотеки, которые вы загружаете с MELPA или Emacs Wiki, были загружены мной. Однако, как и в случае со всем, что есть в Интернете, нет никакой железной гарантии, так же как и с самим кодом. Как говорит реклама GPL в каждой библиотеке GPL:

    Эта программа распространяется в надежде, что она будет полезна, но БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ; даже без подразумеваемой гарантии ТОВАРНОЙ ПРИГОДНОСТИ или ПРИГОДНОСТИ ДЛЯ ОСОБЫХ ЦЕЛЕЙ. Смотрите GNU General Public License для получения более подробной информации.

НТН. Счастливого взлома.


Я уверен, очень обнадеживает.
Nic Ferrier

1
Позвольте мне не согласиться с вашим мнением MELPA. Автор пакета ничего не «выпускает» в MELPA. Он или она просто берет на себя обязательства по собственному репо, и MELPA забирает его. Разница в том, что MELPA выбирает что угодно, в то время как MELPA стабильно выбирает помеченные релизы. На самом деле это вопрос предпочтений. Некоторые люди предпочитают всегда создавать ветвь функций, трактовать ствол как священный и сигнализировать о том, что изменение готово, путем объединения со стволом. Другие развиваются в транке, но помечают готовые выпуски с помощью явных тегов Оба подхода разумны ...
Мекк

1
… Лично я на стороне тегов, так как это дает мне четкое представление о том, когда и почему я делаю релиз (и позволяет публиковать предварительные версии в транке, и избегает необходимости создавать ветви функций для небольших изменений кода, и позволяет мне использовать номера версий для сигнализировать, насколько велики изменения, и позвольте мне использовать понятные человеку номера версий). Итог: до тех пор, пока есть авторы, которые предпочитают помечать релизы, у melpa stable есть свои достоинства - и я бы сказал, что нет ничего плохого в том, что автор управляет выпусками, помечая теги, напротив, это означает, что он или она заботится о том, когда и что следует делать. быть выпущеным.
Мекк
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.