Технические соображения для сопровождающих пакетов, чтобы не использовать менеджер пакетов Emacs?

Я заметил, что некоторые известные разработчики пакетов предпочитают не использовать систему управления пакетами Emacs (ESS?) Или жалуются на ее ограничения (Helm).

Цитируя шлем «S README.md :

ВНИМАНИЕ : из-за неправильной концепции package.el, которая отвечает за выборку helm-файлов и их компиляцию, пользователи чаще всего имели ошибки при обновлении с melpa и list-package. Чтобы избежать этого, Async был добавлен как зависимость от helm, чтобы заставить package.el компилировать свои файлы в чистой среде. Люди, устанавливающие из git и использующие файл make, не пострадают от этой проблемы и не нуждаются в Async, хотя это рекомендуется, поскольку он исправляет установку всех других пакетов, которые вы можете установить с помощью package.el из (m) elpa. Смотрите FAQ для получения дополнительной информации.

На какие именно технические ограничения имеет нынешняя система управления пакетами, на которые они могут ссылаться, и почему пакеты нужно использовать asyncв качестве зависимости?

package package-repositories ess

— Амелио Васкес-Рейна
источник

Я думаю, этот вопрос должен быть закрыт как слишком широкий для этого сайта. Лучше нацелиться на дискуссионный форум. Попробуйте help-gnu-emacs@gnu.org или emacs-devel@gnu.org или Emacs reddit или что-то подобное. «В чем именно проблема? » Предполагает, что есть одна такая проблема, и вопрос о том, какие возможные проблемы существуют для любого пакета (или любого сопровождающего пакета), слишком широк.

— Дрю

ESS размещен на Melpa: melpa.org/#/ess , возможно, это просто документация. Я знаю много проектов, которые обычно устанавливаются через системный менеджер пакетов, но я предпочитаю не упоминать эту опцию без какой-либо реальной причины (возможно, если предположить, что если вы зашли настолько далеко, что загрузили исходники / двоичные файлы с сайта, то у вас должен быть причина сделать это). Я не знаю, какая проблема была у Хелма.

— wvxvw

Ваше название звучит немного странно для меня. Вы хотели написать «менеджеров» дважды, или вы имели в виду сопровождающих?

— Малабарба

Работая в качестве разработчика ESS, дайте нам знать, как мы можем улучшить положение вещей - как прокомментировали другие, ESS работает в MELPA.

— Стивен Эглен

Ответы:

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

В Emacs-25 есть предварительное исправление, но в AFAIK проблема все еще присутствует в 24.5.

— Стефан
источник

За исключением заметного ProofGeneral, я не знаю ни одного крупного пакета Emacs, которого нет в каком-либо архиве ELPA. В частности, ESS находится на MELPA с трех лет . И PG - это отдельная история, и она определенно не репрезентативна для всей экосистемы Emacs.

У ELPA, безусловно, есть свои недостатки, но для подавляющего большинства пакетов он работает просто отлично, даже для крупных, таких как Magit. Хелм - это единственная посылка, в которой я вижу жалобы на ELPA. Я не уверен, что именно они жалуются, но я думаю, что это о компиляции:

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

Будучи самим сопровождающим пакета, я не согласен с этим утверждением. Я склонен винить Хелма, а не ELPA или Emacs. По моему мнению, это утверждение является гиперболой, а проблема - лишь симптомом чрезмерного и недопустимого использования макросов.

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

— lunaryorn
источник

FWIW, я не согласен с вашим несогласием: хотя я согласен с тем, что лучше избегать чрезмерного использования макросов, проблемы компиляции реальны и могут затрагивать не только вызовы макросов (например, они могут быть вызваны также встроенными функциями или вызываемыми функциями). во время макроразложения). И когда вас укусила эта проблема, ваши .elc-файлы некорректны и могут плохо себя вести любыми интересными способами, поэтому может быть трудно диагностировать проблему, и для ее устранения требуется удалить + переустановить пакет (как только вы выяснили, проблема и какой пакет нужно переустановить

— Стефан

@Stefan Я не отрицаю проблем с компиляцией. Я укусила себя. Но мне не нравится отношение, которое отражается в этом заявлении, и отсутствие того, что я бы назвал «сбалансированной точкой зрения». Хельма укусили так плохо, потому что они тоже допустили много ошибок, но их заявление не подтверждает этого. По моему скромному мнению, вызывать функции в макро-теле - такая ошибка. Макросы предназначены только для синтаксиса, но никогда не для функциональности. Но я понимаю, что это, похоже, предмет, по которому у сообщества Emacs Lisp много разных мнений.

— lunaryorn

pinmacs , jdee-emacs и excorporate - это известные пакеты, которых нет ни в одном архиве ELPA (в зависимости от ваших критериев для основных пакетов). Однако подавляющее большинство пакетов.

— Уилфред Хьюз