Что Вы ожидаете от диспетчера пакетов для 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 в состояние, мне нравится он в - все установленные пакеты и набор конфигураций. Объединенный со способностью быть в состоянии легко установить любого по всему сайту (если у Вас есть корневые полномочия) или как отдельный пользователь, я мог бы синхронизировать всего Emacsen везде.

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

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

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

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

я записал:

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

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

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

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

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

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

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

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

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

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

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

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

---

На данный момент, кажется, следует использовать значительно улучшенный ELPA.

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

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

---

На данный момент, кажется, следует использовать значительно улучшенный ELPA.

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

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

---

На данный момент, кажется, следует использовать значительно улучшенный ELPA.

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

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

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

Центральный репозиторий тоже может быть неплохим (например, Emacsmirror ).

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

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

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

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

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

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

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