Технічні міркування щодо технічного обслуговування постачальників не використовувати менеджер пакунків Emacs?

Я помічаю, що деякі помітні обслуговуючі пакети вирішують не використовувати систему управління пакунками Emacs (ESS?) Або скаржитися на її обмеження (Helm).

Цитування з Helm 's README.md :

ПОПЕРЕДЖЕННЯ : Через погану концепцію package.el, яка відповідає за отримання файлів кермів та їх компілювання, у більшості випадків користувачі мали помилки під час оновлення до melpa та list-package. Щоб уникнути цього, Async були додані як залежність від керма, щоб змусити package.el збирати свої файли в чистому середовищі. Люди, що встановлюють з git та використовують файл make, не страждатимуть від цієї проблеми та не потребують Async, хоча це рекомендується, оскільки він фіксує встановлення всіх інших пакетів, які ви можете встановити за допомогою пакета.el від (m) elpa. Додаткову інформацію див. У FAQ.

На які саме технічні обмеження діє поточна система управління пакунками, на яку вони можуть натякати, і чому пакети потрібно використовувати asyncяк залежність?

Проблема, на яку ви посилаєтесь, ймовірно, що коли ви оновлюєте пакет із сеансу Emacs, коли цей пакет уже використовується, стара версія пакета іноді буде перешкоджати під час компіляції нової версії, що призводить до неправильно складених файлів.

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

За винятком винятку ProofGeneral, я не знаю жодного основного пакету Emacs, який недоступний в архіві ELPA. Зокрема, ESS працює на MELPA з трьох років . І PG - це історія сама по собі, і, безумовно, не є репрезентативною для всієї екосистеми Emacs.

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

Під час оновлення Emacs збирає нову версію пакета в середовищі, де стара версія все ще завантажена. Зазвичай це зовсім не шкодить, але може порушити макроси в певних ситуаціях. Emacs складе нову версію проти старої реалізації макросу, що може спричинити поломку, якщо новий код покладається на певну зміну цього макроса.

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

Якщо ви використовуєте багато макросів і, що ще гірше, вписуєте нетривіальний код в тіло макросів, ви просто повинні бути обізнані про наслідки, пов'язані з компіляцією байтів, і вам потрібно бути обережними, щоб підтримувати сумісність з вашими власними макросами. у вашому пакеті. Не робити цього, а замість цього перекладати провину навколо, не дуже приємно. Мої 2 копійки.