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

StackOverflow https://stackoverflow.com/questions/454259

Вопрос

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

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

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

Для версий Emacs старше 24.1:

  • Список лиспов Emacs - Проблема:Я вижу мертвых людей (ссылки).
  • Эмаксвики - Проблема:Может содержать следы nuts (вредоносный код).
  • Эмаксмиррор - Репозиторий пакетов, над которым я работаю.Проблема:Ни один менеджер пакетов пока не поддерживает его изначально.

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

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

ОБНОВЛЕНИЕ -- пакет.el включен в GNU Emacs, начиная с версии 24.1

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

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

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

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

Обсуждения по рассматриваемому вопросу

Вопрос (наконец-то)

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

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

  1. Множество упаковок (the Эмаксмиррор предоставляет самую большую доступную коллекцию пакетов, но пока нет явной поддержки ни в одном диспетчере пакетов).
  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. Предложите альтернативные варианты перед установкой конкретного пакета.

Я надеюсь на такого рода ответы

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

Решение

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

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

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

Подобно тому, как GitHub (использовался для) упрощения публикации RubyGems, я хотел бы видеть нечто подобное в менеджере пакетов Emacs.Например, пометьте свой репозиторий "vX.Y.Z", и ваш elisp goodness автоматически станет доступен всем.

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

Другие советы

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

M-x php-mode

и Emacs был весь такой

M-x php-mode [no match]

когда это должно было быть похоже

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

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

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

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

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

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

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

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

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

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

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

Пока что гораздо улучшенный ELPA кажется подходящим вариантом.

Однажды я потратил некоторое время на написание небольшого менеджера пакетов для Emacs.

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

Я написал:

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

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

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

Мне нравится иметь возможность:

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

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

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

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

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

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

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

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

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

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

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

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

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

Это то, что я хотел бы видеть в emacs.

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

  • явная загрузка пакетов.Нет автоматической установки.Никаких невидимых загрузок.Я хочу запросить новые библиотеки или новую функцию.
  • Я должен иметь возможность указать имя / версию / временную метку установленных пакетов.
  • Если мой друг даст мне свой список, я смогу сравнить его состояние emacs с моим.
  • функция проверки наличия обновлений.Какие обновления доступны?Что они исправляют?
  • проверка соответствия, верификация и загрузка.Если я устанавливаю csharp-mode и для этого требуется версия 5.0.28 cc-mode, то он должен подтвердить мне, что я также должен загрузить cc-mode.
  • должно быть какое-то ранжирование сообществом этих пакетов, например, ранжирование торрентов на isohunt.Я хочу посмотреть, есть ли у пакета 3 положительных голоса или 3000.
  • "транзакционное" поведение.Если установка выходит из строя, ее необходимо размотать до последнего заведомо исправного состояния.
  • безотказные.Если я поместил пользовательские моды в linum.el, он должен отказаться устанавливать новую версию поверх моих изменений, если я явно не разрешу это.Это должно предупредить меня еще до того, как я начну.Сделайте это с контрольными суммами /md5 поверх существующей установки.
  • есть возможность запускать некоторые пакеты из сжатых архивов, таких как zip-файлы.Так что у меня никогда не возникало никаких сомнений в том, что я не обновлял ни один из встроенных elisp.
  • возможность использовать зеркальные хосты для распространения пакетов.
  • вся эта функция должна быть доступна через библиотеку M-x-manageemnt или что-то в этом роде.

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top