Jakie są praktyczne różnice między różnymi repozytoriami pakietów Emacsa?

Zauważam, że istnieje kilka różnych repozytoriów, które często zawierają to samo oprogramowanie. Dlaczego miałbym preferować:

• GNU ELPA
• Marmolada
• MELPA

nad innymi? Ponieważ którekolwiek repozytorium nie zawiera wszystkich pakietów, które chcę, czy dobrym pomysłem jest jednoczesne włączenie tych repozytoriów?

GNU ELPA to oficjalne repozytorium pakietów GNU Emacs. Jest to jedyna domyślnie włączona, co oznacza, że ​​ma największy zasięg. Jednocześnie przesłanie pakietu jest trochę kłopotliwe i wymaga przypisania praw autorskich FSF, co oznacza, że ​​ma on stosunkowo ograniczony wybór pakietów.

MELPA i Marmalade to repozytoria pakietów innych firm. Nie są oficjalnie wspierane przez GNU, ale mają też znacznie większy wybór pakietów. Jakość pakietu jest nieco bardziej zmienna, ale znacznie bardziej prawdopodobne jest znalezienie tego, czego szukasz, szczególnie jeśli jest to nieco niejasne.

Marmolada i MELPA mają nieco inne modele dla osób przesyłających paczki. Rozumiem, że MELPA śledzi repozytorium kontroli wersji bezpośrednio (tj. Przez GitHub), pozwalając autorom pakietów aktualizować pakiety tylko poprzez wypychanie commits do gałęzi. Z drugiej strony Marmalade ma jawne przesyłanie paczek do repozytorium.

W praktyce nie widziałem dużej różnicy między MELPA a Marmoladą. Nie ma wiele wad, aby umożliwić obu z nich jak największy wybór pakietów instalowalnych: używam zarówno (jak i GNU ELPA, oczywiście) od dłuższego czasu bez znaczących problemów.

Jednym z możliwych problemów (których nie spotkałem na sobie) z włączeniem obu repozytoriów, na które nie wpadłem, jest dostępność pakietów z obu wersji. Domyślnie menedżer pakietów ( package.el) nie ma sposobu na rozwiązanie takiego konfliktu; Można to jednak rozwiązać, instalując melpapakiet, który pozwala dostosować, które pakiety są dostarczane lub wykluczane z których repozytoriów. Możesz zobaczyć więcej szczegółów tutaj lub z dokumentacji melpapakietu.

Jak pomocne @Malabarba, problem ten został rozwiązany w Emacs 24.4.

Jeśli naprawdę martwisz się o bezpieczeństwo, możesz uniknąć zarówno MELPA, jak i Marmalade, ponieważ pozwalają każdemu przesyłać pakiety i, o ile mi wiadomo, nie mają żadnych proaktywnych uzgodnień dotyczących bezpieczeństwa. Z drugiej strony repozytorium GNU ELPA jest zarządzane przez FSF i ma podpisane pakiety, które powinny pomóc. Oczywiście, jeśli bezpieczeństwo jest naprawdę ważne, możesz po prostu przejrzeć i zainstalować pakiety elisp ręcznie zamiast korzystać z menedżera pakietów.

Moim zdaniem, niektóre repo wiążą się z większym obciążeniem przesyłaniem pakietów niż inne; repozytoria z większym obciążeniem zwykle mają mniej pakietów. W kolejności od największego do najmniejszego narzutu:

1. GNU ELPA wymaga, aby cały kod był objęty licencją GPL, a prawa autorskie przypisane FSF. Kod ELPA jest w zasadzie „własnością” podstawowego zespołu Emacsa, więc jest go znacznie mniej niż w przypadku innych transakcji repo. (tryb org ma swoje własne repozytorium, ale ma ten sam tryb działania.)
2. Marmalade wymaga, aby cały kod posiadał licencję zgodną z GPL, a wszystkie pakiety są przesyłane ręcznie. Własność jest trochę nieokreślona, ​​a zmiana własności nie ma ustalonego procesu AFAIK.
3. MELPA Stable jest mniej więcej bezpośrednią konkurencją dla Marmalade, z tym wyjątkiem, że nie ma ograniczeń licencyjnych i automatycznie buduje pakiety z repozytoriów git przy użyciu najnowszej oznaczonej wersji. Własność jest określana za pomocą repozytorium MELPA (zmiany własności następują w wyniku żądania ściągnięcia).
4. MELPA jest jak stabilny MELPA, tyle że zawsze pobiera najnowszą wersję gałęzi master repozytorium git. Pakiety mają tendencję do „najnowocześniejszych” i mogą być trochę za darmo pod względem stabilności (co ma zalety i wady).

Osobiście uważam, że MELPA Stable lub Marmalade prawdopodobnie wygra na dłuższą metę dla większości użytkowników - właściwa MELPA jest dość niestabilna, a ELPA jest zbyt restrykcyjna, aby była naprawdę skalowalna dla wielu pakietów. Ale to tylko opinia.

Dostępnych jest kilka repozytoriów pakietów.

Urzędnik

GNU ELPA to oficjalne repozytorium pakietów. Jest mały i wymaga przypisania praw autorskich (wszystkich autorów pakietu) do FSF, aby mógł się do niego przyczynić.

Pakiety GNU ELPA to tak naprawdę repozytorium git . Zaletą hostowania tutaj jest to, że główny zespół próbuje aktualizować pakiety, jeśli sam Emacs dodaje lub przestaje działać.

Zbudowany ze źródła

MELPA to największe i najszybciej rozwijające się repozytorium pakietów. Wydaje nową wersję za każdym razem, gdy nowa wersja jest przekazywana do repozytorium lub strona EmacsWiki jest aktualizowana.

To krwawiąca przewaga, ale w praktyce działa bardzo dobrze. MELPA jest wyselekcjonowana, aby uniknąć duplikatów pakietów i zapewnić rejestrację kanonicznego katalogu głównego pakietu (zamiast losowego rozwidlenia).

MELPA ma problem polegający na tym, że wersje są tylko znacznikami czasu, np my-package-20131231.2359. Oznacza to, że jeśli zależysz od mojego pakietu:

;; Package-Requires: ((my-package "1.2.3"))

wtedy Emacs pomyśli, że każda wersja MELPA jest wystarczająco nowa.

MELPA Stabilny jest taki sam jak MELPA, ale zamiast używać wersji datestamp, używa wersji w tagach git. Pozwala to na lepsze rozwiązywanie zależności, ale ma problemy z zależnością od pakietów wiki .

Przesłane przez użytkownika

Marmolada bardziej przypomina tradycyjne repozytorium z innych języków programowania. Twórca pakietu przesyła pakiet do Marmalade po wydaniu.

Zasadniczo zapewnia to poprawny proces wydawania pakietów (Marmalade wyprzedza stabilną wersję MELPA), a także pozwala uniknąć problemu z automatycznym generowaniem numeru wersji. Nie ma jednak weryfikacji tożsamości. Każdy może przesłać pakiet, nawet jeśli go nie napisał. Staje się to trudne, jeśli opiekun my-packageodkryje, że ktoś inny przesłał my-packagei nie może później przesłać nowych wersji.

Marmolada była kiedyś aplikacją node.js, a teraz jest napisana w elisp. Obie wersje miały czasami problemy z czasem pracy.

Specyficzne dla projektu

Tryb ELPA w trybie Org to repozytorium, które obsługuje tylko orgi org-plus-contrib. Tryb Org jest częścią rdzenia Emacsa, ale został opracowany zewnętrznie, a kod jest okresowo synchronizowany z pniem Emacsa. To repo pozwala Ci na najnowocześniejszy tryb org.

User42 ELPA to repozytorium dla jednego dewelopera pakietów, który wydał całkiem sporo pakietów Emacsa . Jeśli podoba Ci się któryś z jego pakietów, możesz dodać to repo.

Sunrise Commander ELPA to repozytorium rozszerzeń dla Sunrise Commander (pakiet Emacsa do przeglądania plików, zainspirowany przez północnego dowódcę).

Na emeryturze

ELPA firmy Tromey była pierwszą konfiguracją repo. Oficjalnie został zastąpiony GNU ELPA, ale nie miał takich samych wymagań dotyczących przypisania praw autorskich. Od 2010 r. Nie jest już aktualizowany.

Archiwum pakietów Elpy zawierało różne pakiety opracowane przez Jorgena Schaefera dla „Elpy, środowisko programistyczne Emacsa Pythona” , ale migracja do MELPA Stable.

Kilka dodatkowych informacji w celu uzupełnienia innych odpowiedzi tutaj.

1. Niektóre informacje o MELPA i MELPA „stabilne” -

   Zacznij od spojrzenia na to dość zduplikowane pytanie z StackOverflow, w tym komentarze do samego pytania. W szczególności ten komentarz, który zamieściłem po wymianie wiadomości e-mail z Donaldem Curtisem (opiekunem MELPA i stabilnej wersji MELPA):

   Z jego punktu widzenia [Donalda Curtisa i, jak rozumiem jego komunikat do mnie], „stabilna” strona MELPA działa tylko w trybie konserwacji . A jedynym powodem, dla którego nie ma kodu takiego jak mój, jest to, że nikt nie zaimplementował przesyłania z wiki [Emacs Wiki] dla strony „stabilnej”. Ponadto, nikt nie dokonuje „kuracji” - nie ma filtrowania w celu ustalenia, czy pakiet jest stabilny, ryzykowny itp. Niektórzy twórcy pakietów zażądali istnienia dwóch witryn, którzy chcieli odróżnić wersje deweloperskie swoich pakietów od starszych („stabilne” ”) wersje.

   Podsumowując, nie ma nic bardziej „stabilnego” w treści „stabilnej MELPA” . Numeracja wersji i metoda kanału mogą być różne; to wszystko. A jeśli konkretny opiekun pakietu chce odróżnić wersje „stabilną” od „rozwojowej” i chce to zrobić, przesyłając je do dwóch różnych stron, to taki jest efekt - dla tego pakietu .

2. Jedną różnicą między MELPA a Marmalade (i GNU ELPA) jest to, że nie jest wymagane, aby kod wnoszony do MELPA pochodził z repozytorium git. W szczególności można go automatycznie pobrać z Elisp Area of ​​Emacs Wiki .

   Czy to oznacza, jak niektórzy powiedzieli, że każdy może przesłać cokolwiek, a ty nie masz możliwości dowiedzenia się, czy kod jest rzeczywiście przez autora, którego dotyczy roszczenie itp.? Tak i nie. Zasadniczo tak: każdy może przesłać kod Elisp na Wiki Emacs. Jak mówi góra strony Elisp-Area:

   Jest to obszar elisp EmacsWiki, w którym zbieramy pliki EmacsLisp. Nie wymaga logowania, kontroli wersji, nie wymaga ftp, nie wymaga hasła. To tak proste jak sama wiki. Oznacza to również, że każdy może umieścić złośliwy kod w tych plikach EmacsLisp. W razie wątpliwości nie używaj ich.

   Jednak dla pewności jestem administratorem wiki, a moje własne biblioteki Lisp w obszarze Elisp wiki są zablokowanymi stronami. Oznacza to, że tylko administrator wiki może je przesyłać. Więc w tym przypadku możesz być całkiem pewien, że moje biblioteki, które pobierasz z MELPA lub Emacs Wiki, zostały przesłane przeze mnie. Podobnie jak w przypadku wszystkich elementów w Internecie, nie ma jednak gwarancji żelaznej, podobnie jak w przypadku samego kodu. Jak głosi napis GPL w każdej bibliotece GPL:

   Ten program jest rozpowszechniany w nadziei, że będzie przydatny, ale BEZ ŻADNEJ GWARANCJI; bez dorozumianej gwarancji PRZYDATNOŚCI HANDLOWEJ ani PRZYDATNOŚCI DO OKREŚLONEGO CELU. Zobacz GNU General Public License, aby uzyskać więcej informacji.

HTH. Miłego hakowania.