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

Ответ 1

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

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

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

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

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

Ответ 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-режим для меня. Это сделало бы мой день там.

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

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

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

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

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

Ответ 7

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

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

Я написал:

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

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

Ответ 8

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

Мне нравится уметь:

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

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

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

Ответ 9

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

Ответ 10

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

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

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

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

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

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

Ответ 11

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

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

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

Что я хотел бы видеть в emacs.

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

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

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

Ответ 12

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

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