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

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

M-x php-mode

и Emacs был весь как

M-x php-mode [no match]

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

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

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

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

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

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

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

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

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

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

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

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

пока, a гораздо лучше ELPA, кажется, путь.

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

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

Я писал:

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

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

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

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

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

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

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

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

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

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

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

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

Итак, менеджер пакетов, такой как 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 от моего.
• функция проверки обновлений. Какие обновления доступны? Что они исправляют?
• проверка depedency, проверка и загрузка. Если я устанавливаю CSharp-mode и для этого требуется v5.0.28 из cc-mode, тогда он должен подтвердить со мной, что я также должен загрузить cc-mode.
• должно быть что-то вроде сообщество рейтинг этих пакетов, как рейтинг торрентов на isohunt. Я хочу посмотреть, имеет ли пакет 3 upvotes или 3000.
• "транзакций" поведения. Если установка идет бум, она должна расслабиться до последнего удачного состояния.
• газа. Если я поставил пользовательские моды в linum.el, он должен отказаться устанавливать новую версию поверх моих изменений, если я явно не разрешу это. Он должен предупредить меня еще до начала. Сделайте это с контрольными суммами/md5 над существующей установкой.
• есть возможность запуска некоторых пакетов из сжатых архивов, таких как zip-файлы. Поэтому я никогда не иметь никаких сомнений в том, что у меня не обновляется любой из embbedded elisp.
• возможность использования зеркальных хостов для распространения пакетов.
• вся эта функция должна быть доступна через библиотеку M-x-manageemnt или что-то еще.

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

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

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