Что вы ожидаете от менеджера пакетов для 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 maintainer работает только в небольших масштабах.

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

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

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

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

---

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

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

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

Я писал:

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

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

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

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

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

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

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

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

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

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

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

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

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