Я помічаю, що є кілька різних сховищ, які часто містять одне і те ж програмне забезпечення. Чому я хотів би віддати перевагу:
над іншими? Оскільки будь-яке одне сховище не містить усіх пакунків, які я хочу, чи є гарною ідеєю одночасне включення цих сховищ?
Відповіді:
GNU ELPA є офіційним сховищем пакетів GNU Emacs. Це єдиний, включений за замовчуванням, а це означає, що він має найбільше охоплення. У той же час, подаючи пакет, є певні клопоти і вимагає присвоєння авторських прав FSF, а це означає, що він має відносно обмежений вибір пакетів.
MELPA та Marmalade - це сторонні сховища пакетів. Вони офіційно не підтримуються GNU, але також мають значно більший вибір пакетів. Якість упаковки дещо змінна, але ви набагато більше шансів знайти те, що шукаєте, особливо якщо це трохи неясно.
Мармелад та MELPA мають дещо різні моделі для завантажувачів пакетів. Я розумію, що MELPA відстежує сховище контролю версій безпосередньо (тобто через GitHub), дозволяючи авторам пакунків оновлювати пакети лише натисканням комісій на гілку. У Marmalade, навпаки, люди явно завантажують пакунки в сховище.
На практиці я не бачив великої різниці між MELPA та Marmelade. Не дуже багато недоліків у тому, щоб вони могли мати якнайбільший вибір встановлених пакетів: я використовував і те, і інше (і GNU ELPA, звичайно), не маючи значних проблем.
Однією з можливих проблем (яку я не натрапив на себе) тим, що ввімкнено обидва сховища, які я не натрапив на себе, - це наявність пакетів для обох версій. За замовчуванням менеджер пакунків ( package.el) не має жодного способу вирішити подібний конфлікт; однак ви можете вирішити це, встановивши melpaпакет, який дозволяє налаштувати, які пакунки надаються або виключені з яких сховищ. Більш детальну інформацію ви можете побачити тут або з документації на melpaпакет.
Як з користю вказав @Malabarba, ця проблема вирішена в Emacs 24.4.
Якщо ви дійсно переживаєте за безпеку, ви можете уникати MELPA і Marmalade, оскільки вони дозволяють будь-кому завантажувати пакунки і, наскільки я знаю, не мають жодних активних заходів щодо безпеки. З іншого боку, сховищем GNU ELPA керує FSF і має підписані пакети, які повинні допомогти. Звичайно, якщо безпека дійсно важлива, ви можете просто переглянути і встановити пакети elisp вручну, а не використовувати менеджер пакунків.
Як я думаю про це, деякі репости мають більше витрат на участь у поданні пакетів, ніж інші; репости з більшою накладною кількістю мають менше пакетів. Для того щоб від більшості до мінімуму накладні:
Особисто я думаю, що або MELPA Stable, або Marmelade, ймовірно, виграють у довгостроковій перспективі для більшості користувачів - власне MELPA є досить нестабільним, а ELPA занадто обмежувальним, щоб бути дійсно масштабованим для багатьох пакетів. Але це лише думка.
Є кілька сховищ пакетів.
Офіційна
GNU ELPA - офіційний пакет репо. Він невеликий і вимагає присвоєння авторських прав (усіх авторів пакету) ФФС, щоб зробити його внеском.
Пакети GNU ELPA - це справді лише gpo repo . Перевага розміщення тут полягає в тому, що основний колектив намагається оновити пакети, якщо Emacs сам додає або знецінює функції.
Побудовано з джерела
MELPA - це найбільший і найшвидше зростаючий репо пакет. Він випускає нову версію кожного разу, коли нову версію буде натиснуто на репо, або оновлюється сторінка EmacsWiki.
Це кровотеча, але це дуже добре працює на практиці. MELPA призначений для уникнення дублікатів пакунків та для того, щоб записати канонічну основу пакету (замість випадкової вилки).
У MELPA є проблема, що версії - це лише часові позначки, наприклад my-package-20131231.2359. Це означає, що якщо ви залежите від мого пакета:
;; Package-Requires: ((my-package "1.2.3"))
тоді Emacs подумає, що будь-яка версія MELPA є достатньо новою.
MELPA Stable - це те саме, що і MELPA, але замість того, щоб використовувати версії datestamp, він використовує версії в тегах git. Це дозволяє краще вирішити залежність, але має проблеми з залежністю від пакетів вікі .
Користувачі завантажують
Мармелад набагато більше схожий на традиційний сховище з інших мов програмування. Розробник пакунка завантажує пакунок у Marmalade, коли вони випускають.
В принципі, це дає пакетам належний процес випуску (Marmalade раніше MELPA стабільний), а також уникає проблеми з автоматичною генерацією версії. Однак підтвердження особи не існує. Кожен може завантажити пакет, навіть якщо він його не написав. Це стає складним, якщо керівник my-packageвиявить, що хтось ще завантажив my-packageі не може згодом завантажити нові версії.
Мармелад раніше був додатком node.js, і тепер це написано в elisp. Обидві версії періодично мали проблеми з поновленням.
Конкретний проект
ELPA-режим ELPA - це репо, що містить лише хостинг orgта org-plus-contrib. Org-режим є частиною ядра Emacs, але він розроблений зовні і код періодично синхронізується лише з магістраллю Emacs. Це репо дозволяє вам мати режим кровоточивого органу.
User42 ELPA - це репортаж для одного розробника пакунків, який випустив цілий спектр пакетів Emacs . Якщо вам сподобався будь-який з його пакетів, ви можете додати це репо.
Sunrise Commander ELPA - це репортаж розширень для Sunrise Commander (пакет Emacs для перегляду файлів, натхненний командиром опівночі).
Пенсіонер
ELPA Tromey була першою репо- групою . Він офіційно замінений GNU ELPA, але він не мав однакових вимог щодо присвоєння авторських прав. Станом на 2010 рік він більше не оновлюється.
Архів пакетів Elpy містив різні пакети, розроблені Йоргеном Шефером для "Elpy, середовище розробки Emacs Python" , але вони перейшли до MELPA Stable.
no one has mentioned the risks involved in using github, a commercial provider of web based software, as a backend: але я впевнений, що ці проблеми зникнуть тепер, коли це Microsoft GitHub ;-)
Деякі додаткові відомості, щоб доповнити інші відповіді тут.
Деяка інформація про MELPA та MELPA "стабільний" -
По - перше, переглянувши це досить повторюване запитання із StackOverflow, включаючи коментарі до самого питання. Зокрема, цей коментар, який я опублікував, обмінявшись електронною поштою з Дональдом Кертісом (підтримувачем MELPA та стабільної MELPA):
З його точки зору [Дональд Кертіс, і як я розумію його спілкування зі мною], "стабільний" сайт MELPA знаходиться лише в режимі обслуговування . І єдина причина, що такий код, як мій, не в тому, що ніхто не здійснив завантаження з вікі [Emacs Wiki] для "стабільного" сайту. Крім того, не відбувається "курітування" кимсь - немає фільтрації, щоб визначити, чи стабільний пакет, ризикований і т. Д. Про існування двох сайтів вимагали деякі розробники пакетів, які хотіли відрізнити версії розробників своїх пакетів від старих ("стабільні") ") версії.
Підсумовуючи, немає нічого, що по суті є більш "стабільним" щодо вмісту на "MELPA stable" . Нумерація версій та спосіб подачі можуть бути різними; це все. І якщо певний обслуговуючий пакет бажає відрізнити "стабільну" від "розробки" версії, і хоче це зробити, завантаживши їх на два різні сайти, то такий ефект - для цього пакету .
Одна відмінність між MELPA і Marmalade (і GNU ELPA) полягає в тому, що не потрібно, щоб код, який сприяв тому, щоб MELPA отримувався з сховища git. Зокрема, його можна автоматично витягнути з області Elisp Wiki Emacs Wiki .
Чи означає це, як дехто казав, що кожен може завантажувати що завгодно, і ви не можете знати, чи дійсно код заявляється автором тощо? Так і ні. Загалом, так: кожен може безкоштовно завантажити код Elisp в Emacs Wiki. Як вгорі сторінки Elisp-Area сказано:
Це область elisp EmacsWiki, де ми збираємо файли EmacsLisp. Не потрібно входити в систему, не потрібно контролювати версію, не потрібний ftp, не потрібен пароль. Це так само просто, як і сама вікі. Це також означає, що в ці файли EmacsLisp кожен може розміщувати шкідливий код. Якщо ви сумніваєтесь, не використовуйте їх.
Однак, як тільки ви знаєте, я адміністратор вікі, і мої власні бібліотеки Lisp у Вікі-області Elisp - це заблоковані сторінки. Це означає, що завантажувати їх може лише адміністратор вікі. Тож у цьому випадку ви можете бути впевнені, що мої бібліотеки, які ви завантажуєте з MELPA або Emacs Wiki, були завантажені мною. Як і у всьому Інтернеті, однак, немає гарантії на залізо, так само як немає гарантії з самим кодом. Як говорить розмиття GPL у кожній бібліотеці GPL:
Ця програма поширюється з надією, що вона буде корисною, але БЕЗ БУДЬ-ЯКОЇ ГАРАНТІЇ; навіть не маючи на увазі гарантії ПРОДАЖУВАННЯ або ФІТНІСНОСТІ ДЛЯ ДІЯЛЬНОЇ МЕТА Детальнішу інформацію див. У Загальній публічній ліцензії GNU.
HTH. Щасливий злом.