Что вы ожидаете от менеджера пакетов для Emacs?

Question

Хотя существует несколько тысяч библиотек Emacs Lisp, GNU Emacs, до версии 24.1 не было (внутреннего) менеджера пакетов.

Я предполагаю, что большинство пользователей согласятся с тем, что в настоящее время довольно неудобно находить, устанавливать и особенно поддерживать современные библиотеки Emacs Lisp.

Страницы, которые делают жизнь немного легче

Для версий Emacs старше 24,1:

• Emacs Lisp List - Проблема: Я вижу мертвых людей (ссылки).
• Emacswiki - Проблема: Может содержать следы орехов (вредоносный код).
• Emacsmirror - Репозиторий пакета, над которым я работаю. Проблема: пакетный менеджер еще не поддерживает его.

Некоторые менеджеры пакетов

Это не то, что еще никто не пытался. (Некоторые из них не существовало, когда этот вопрос был задан.)

• auto-install
• borg.el - ассимилировать Emacs пакеты с помощью Git подмодулей.
• el-get.el - Поддерживается множество источников.
• elinstall.el
• epackage ака DELPS - концепция упаковки Debian, применяемая для пакетов Emacs Lisp.
• epkg.el - Это теперь только инструмент для просмотра Emacsmirror.
• install.el
• install-elisp.el
• jem-pkg.el
• package.el - ЭЛПА. Похоже, он будет включен в Emacs 24.

---

UPDATE - package.el входит в GNU Emacs, начиная с версии 24,1

---

• pases.el
• pelm - Установщик командной строки; используя php.
• plugin.el
• straight.el - Недавний и экспериментальный, не достиг 1.0 релиз еще.
• use-package.el
• XEmacs package manager

пакет был включен в багажнике Emacs. epkg еще не готов, а также в настоящее время недоступен. По крайней мере, install-elisp, плагин и пакет использования, похоже, больше не поддерживаются.

Я создал git repository, содержащий все эти менеджеры пакетов в качестве подмодулей.

Некоторых утилиты, которые могут быть полезны

Менеджеры пакетов могут использовать эти утилиты и/или они могут быть использованы для поддержания зеркала пакетов.

• date-calc.el - Процедуры расчета и разбора даты.
• ell.el - Просмотреть список Emacs Lisp.
• elm.el, elx.el, xpkg.el - Используется для поддержания Emacsmirror.
• genauto.el - Помогает генерировать автозагрузки для ваших пакетов elisp.
• inversion.el - Требует определенных версий пакета.
• loadhist.el, lib-requires.el, elisp-depend.el - Команды для отображения зависимостей библиотеки Emacs Lisp.
• project-root.el - Определите корень проекта и выполните действия на его основе.
• strptime.el - Частичная реализация анализа времени и времени POSIX.
• wikirel.el - Посетите соответствующие страницы в Emacs Wiki.

дискуссии о предмете под рукой

• emacs-devel 20080801
• comp.emacs 20021121
• RationalElispPackaging

вопрос (наконец)

Так что - я хотел бы узнать от вас, что вы считаете важным/несущественным/дополнительным и т. Д. В диспетчере пакетов для Emacs.

Некоторые идеи

1. Многие пакеты (Emacsmirror предусматривает, что самый большой доступный набор пакетов, но нет явной поддержки в любом менеджере пакетов еще).
2. Только те пакеты, которые были протестированы.
3. Поддержка нескольких архивов пакетов (так что люди могут выбирать между многими/проверенными пакетами).
4. Зависимость, рассчитанная только на основе обязательных функций.
5. Зависимости учитывают конкретные версии.
6. Используйте только версии, выпущенные выше по течению.
7. Используйте версии систем управления версиями, если они доступны.
8. Пакеты классифицируются.
9. Пакеты можно удалить и обновить не только.
10. Поддержка создания вилки восходящей версии пакетов.
11. Поддержка публикации этих вилок.
12. Поддержка выбора вилки.
13. После установки пакетов установки.
14. Создавать файлы автозагрузки.
15. Интеграция с Emacswiki (см. Wikirel.el).
16. Пользователи могут помечать, комментировать и т. Д. Пакеты и делиться этой информацией.
17. Только программное обеспечение, назначенное FSF/GPL/FOSS, или не заботятся о лицензии.
18. Менеджер пакетов должен быть интегрирован с Emacs.
19. Поддержка для автоматического контакта с автором.
20. Много метаданных.
21. Предложите альтернативы перед установкой определенного пакета.

Я надеюсь на эти виды ответов

• Указатели на более реализациях, дискуссии и т.д.
• длинномерные описания набора функций, которые делают ваш идеальный менеджер пакетов.
• Описание одной конкретной желаемой/нежелательной функции. Не стесняйтесь подробно излагать мои идеи сверху.
• Удивите меня.

Answer 1

Автоматическая публикация от контроля версий

Я хотел бы видеть стандарт, центральный и одного Emacs менеджер пакетов. Прямо сейчас, я положил свои деньги на ELPA, но еще предстоит пройти долгий путь.

Самое большое, что поможет менеджеру пакетов Emacs, было бы сделать его тривиальным для публикации пакетов. На мой взгляд, я бы хотел, чтобы это произошло в сочетании с системой управления версиями , такой как git на центральной платформе , например GitHub - что-то, что облегчило бы публикацию своих пакетов и сделало бы это легко для других, чтобы внести свой вклад.

Как и в случае с GitHub (обычно), вы можете легко публиковать RubyGems, я бы хотел увидеть что-то подобное в менеджере пакетов Emacs. Например, поместите свой репозиторий в «vX.Y.Z» и получите доступ к своим свойствам elisp для всех.

Дополнительным преимуществом использования популярных бэкэнд, таких как GitHub, является то, что вы сразу получите много информации, которая должна помочь добиться успеха.

Answer 2

Я все еще изучаю Emacs, поэтому у меня не было возможности заглянуть в менеджеров пакетов, но отличная функция - сообщить пользователю, что пакет доступен, если они пытаются его использовать, но это не на их системе. Например, я хотел когда-то изменить PHP файл на сервере, и я попытался

M-x php-mode 

и Emacs все нравится

M-x php-mode [no match] 

, когда оно должно было быть как

php-mode available from ftp.gnu.org. install? (y/n) 

и тогда он установил и загрузил php-режим для меня. Это сделало бы мой день прямо здесь.

Answer 3

Простая синхронизация конфигурации: Я, как и многие люди, использую Emacs на разных компьютерах и серверах, некоторые из них мои, а некоторые нет.Было бы замечательно, если бы у менеджера пакетов был какой-то файл, который я мог бы перевести с одного компьютера на другой; то на последнем компьютере менеджер пакетов перенесет мой Emacs в состояние, в котором мне это нравится, - все установленные пакеты и конфигурации. В сочетании с возможностью иметь возможность легко устанавливать любой сайт (если у вас есть права root) или как один пользователь, я мог бы синхронизировать все Emacsen повсюду.

Answer 4

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

Например, причина, по которой Debian (и ее производные: Ubuntu и т. Д.) Настолько хороша, что вы можете с радостью использовать свою систему, не устанавливая что-то вне репозиториев, и что все на ней тщательно протестировано. Фактические функции диспетчера пакетов важны, но вторичны для самих управляемых пакетов.

Answer 5

Помимо упомянутого выше, я ожидаю нечто вроде debian и других репозиториев - набор стабильных, экспериментальных, непроверенных пакетов. Возможность добавлять свои собственные репозитории - я использую много пакетов непосредственно из VCS, поэтому было бы полезно создать свои собственные пакеты.

Answer 6

Я когда-то провел некоторое время, написав небольшой менеджер пакетов для Emacs.

http://gmarceau.qc.ca/plugin.el

Я писал:

Plugin моя попытка создать менеджера в пакета для Emacs. Плагин автоматически загружает Emacs расширения, распаковывает их в директории , добавляет этот каталог в нагрузке пути, генерирует автозагрузку аннотаций, и изменить ваши доты-Emacs файла. Аннотации с автоматической загрузкой - это небольшая известная функция Emacs .После того, как они сгенерированы, расширения Emacs загружаются быстро и постепенно, что действительно приятно, если у вас столько же расширений, сколько и у меня.

Вам понадобятся две библиотечные файлы, чтобы заставить его работать, loop-constructs.el и record.el

Answer 7

Я думаю, что хакеры для iPhone получил достаточно близко к тому, что я хочу, как и в Ubuntu «склонный».

Мне нравится быть в состоянии:

• добавить
• удалить (пакет только)
• пользовательские настройки удалить
• документация Просмотр
• обновление (после прочтения журнала изменений)
• добавить новый архив (aka добавить репозиторий)
• см. Зависимости
• см версии
• поиск имени, ключевое слово
• Поиск по (дате добавления, дате изменения, имя)
• сохранить все установленные пакеты & настройки
• нагрузки набор пакетов & настройки

Мне хотелось бы, чтобы основной набор вещей, которые все работают красиво и являются рекомендуемым способом сделать что угодно. Затем глобальный набор, в котором все работает. Тогда возможность для каждого размещать собственный архив.

Было бы хорошо, если бы все это было связано с git/svn/what, чтобы вы могли устанавливать старые версии. Сделайте свои собственные патчи путем форкирования и т. Д. И т. Д. И т. Д.

Answer 8

Я почти уверен, что лучшее решение включает в себя отправку большего количества пакетов в ELPA и добавление поддержки с несколькими источниками для package.el. Сторонники Emacs заявили, что они рассмотрят возможность включения package.el в версию 24, если он по умолчанию указывает на репозиторий FSF.

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

Answer 9

Независимо от того, как это делается, самая важная вещь, на мой взгляд, заключается в том, что должно быть тривиально отправлять пакеты в репозиторий. В то же время мы не хотим, чтобы эти пакеты были мгновенно доступны для защиты от вредоносного кода (и из-за проблем с лицензированием). Если не существует системы доверия, основанной на криптографических подписях.

Также полезно:

• "метапакетов", чтобы установить несколько пакетов одновременно.
• Точно так же мы должны иметь возможность устанавливать набор файлов elisp для ремонтопригодности
• «Неработающие» пакеты не должны прерывать запуск Emacs. Это легко, и я реализовал его самостоятельно.emacs
• Возможность установки файлов, отличных от сценариев. Это часто упускается из виду, но очень полезно. Вы могли бы, например, отправлять изображения, значки, панели инструментов и т. Д.
• Версия для версии: пакет X требует пакета Y> 1.0
• Тестирование: выполнять основные проверки работоспособности, тестировать конфликты (привязки клавиш, переопределение функций , функции, которые, как ожидается, будут присутствовать, но не будут и т. д.).
• ОШИБКА ОТКАЗА: Я не могу подчеркнуть важность этого достаточно. Наличие централизованного места для уведомления об ошибках пакетов (и возможность отслеживать их) чрезвычайно важно для обеспечения качества пакетов.

Возможно, что-то вроде сжатого архива лучше всего выполнить некоторые из вышеперечисленных.

---

До сих пор кажется, что намного лучше ELPA.

Answer 10

Менеджеры пакетов не предлагают ничего ценного w.r.t. однофайловые пакеты elisp с простыми зависимостями: добавление и удаление с site-lisp никогда не вызывало проблем. Это пакеты, которые зависят от внешних программ (например, ispell), многофайловых пакетов (например, auctex, org-mode), которые могут быть сложными. Не могу придумать какой-либо одноэлементный пакет elisp с нетривиальными зависимостями.

Для этого, за исключением менеджера пакетов, я бы хотел, чтобы пакеты emisps elisp получили пакеты тестов, которые могут запускаться в массовом порядке и которые предоставляют полезную информацию в случае сбоев зависимости.

Answer 11

Я думаю, что менеджер пакетов должен обладать большим вдохновением от Rubygems. Я также думаю, что у него должен быть сайт вроде Gemcutter.

Центральный репозиторий также может быть приятным (например, Emacsmirror). Однако это может быть необязательно, если существует такой сайт, как Gemcutter, который собирает все пакеты.

Я думаю, что эти вещи важны для этого.

• Центральное расположение какого-то, который собирает все пакеты
• Легко добавить пакеты
• Легко поддерживать пакеты
• Легко внести свой вклад в другие пакеты
• Простота установки, удаления и обновления пакетов
• Возможность добавления зависимостей пакетов
• Общая структура для всех упаковок

Таким образом, менеджер пакетов, такой как Rubygems с таким сайтом, как Gemcutter и центральный репозиторий, такой как Emacsmirror (желательно на Github из-за его социального кодирования), действительно сделает Emacs действительно хорошим.

В целом, я думаю, что из Rails следует извлечь много вдохновения и как Rails обрабатывает драгоценные камни.

Answer 12

Не знаю, как новый этот вопрос ...
, но модель, которую я хотел бы увидеть, - CPAN. Я также не знаю Rubygems, но это похоже на CPAN.

CPAN - это архив perl + система управления библиотекой. Когда мне нужно написать программу perl, которая требует ... FTP или SOAP или JSON или XML или ZIP или ... и т. Д., Я могу запустить диспетчер пакетов CPAN, выбрать требуемый пакет для загрузки, просмотра и проверки зависимостей, затем установите все. CPAN зеркалируется .. «везде».

CPAN прекрасно работает для моих целей, и что-то подобное для emacs было бы неплохо иметь. Он также поддерживает построение кода C/C++ по требованию.

Вот что я хотел бы увидеть в emacs.

Некоторые дополнительные комментарии к требованиям.

• Явная загрузка пакетов. Нет автоматической установки. Нет невидимых загрузок. Я хочу попросить новые библиотеки или новую функцию.
• Я должен иметь возможность указать имя/версию/метку времени установленных пакетов.
• Если мой друг дает мне свой список, я должен уметь отличать его состояние от моего противника.
• проверка на работоспособность функция. Какие обновления доступны? Что они исправить?
• проверка, проверка и загрузка. Если я устанавливаю csharp-режим, и для него требуется v5.0.28 cc-mode, то он должен подтвердить, что я также должен скачать cc-mode.
• Должен быть какой-то рейтинг сообщества этих пакетов, например, торренты торрента на isohunt. Я хочу посмотреть, есть ли у пакета 3 upvotes или 3000.
• «транзакционное» поведение. Если установка идет бум, она должна расслабиться в состоянии, известном в последнее время.
• failafes. Если я поместил пользовательские моды в linum.el, он должен отказаться от установки новой версии поверх моих изменений, если я ее явно не разрешаю. Он должен предупредить меня, прежде чем начинать. Сделайте это с помощью контрольных сумм/md5 по существующей установке.
• имеют возможность запускать некоторые пакеты из сжатых архивов, таких как zip-файлы. Поэтому у меня нет никаких сомнений в том, что я не обновил ни один из вложенных elisp.
• возможность использования зеркальных хостов для распространения пакетов.
• вся эта функция должна быть доступна через M-x library-manageemnt или что-то еще.

Наконец, было бы неплохо иметь способ отделить или организовать библиотеки функций. Иерархические пространства имен. Плоское пространство Emacs очень устарело. Это своего рода независимая, но дополняющая основные функции управления пакетами. Я не гусистый гуру, поэтому я не знаю, как это тяжело. возможно, уже есть способ сделать это.