Noto che esistono diversi repository che spesso contengono lo stesso software. Perché dovrei preferire:
sugli altri? Poiché un repository non contiene tutti i pacchetti che desidero, è una buona idea avere questi repository abilitati contemporaneamente?
Risposte:
GNU ELPA è il repository di pacchetti GNU Emacs ufficiale. È l'unico abilitato per impostazione predefinita, il che significa che ha la massima portata. Allo stesso tempo, l'invio di un pacchetto comporta una seccatura e richiede un'assegnazione del copyright FSF, il che significa che ha una selezione relativamente limitata di pacchetti.
MELPA e Marmalade sono entrambi repository di pacchetti di terze parti. Non sono ufficialmente supportati da GNU, ma hanno anche selezioni di pacchetti molto più grandi. La qualità del pacchetto è un po 'più variabile, ma è molto più probabile trovare ciò che stai cercando, soprattutto se è un po' oscuro.
Marmalade e MELPA hanno modelli leggermente diversi per i caricatori di pacchetti. La mia comprensione è che MELPA tiene traccia direttamente di un repository di controllo versione (ovvero tramite GitHub), consentendo agli autori dei pacchetti di aggiornare i pacchetti semplicemente spingendo i commit in una succursale. In Marmalade, d'altra parte, le persone caricano esplicitamente i pacchetti nel repository.
In pratica, non ho visto molta differenza tra MELPA e Marmalade. Non c'è molto svantaggio nel consentire a entrambi di avere la più ampia selezione possibile di pacchetti installabili: sto usando entrambi (e GNU ELPA, ovviamente) per un po 'senza problemi significativi.
Una possibile preoccupazione (che non mi sono imbattuto in me stesso) con entrambi i repository abilitati, che non ho incontrato in me stesso, è avere pacchetti disponibili da entrambi in versioni diverse. Per impostazione predefinita, il gestore pacchetti ( package.el) non ha alcun modo di risolvere conflitti come questo; tuttavia, è possibile risolvere questo problema installando il melpapacchetto che consente di personalizzare quali pacchetti vengono forniti o esclusi da quali repository. Puoi vedere maggiori dettagli qui o dalla documentazione per il melpapacchetto.
Come ha sottolineato utile @Malabarba, questo problema è stato risolto in Emacs 24.4.
Se sei davvero preoccupato per la sicurezza, potresti voler evitare sia MELPA che Marmalade perché consentono a chiunque di caricare pacchetti e, per quanto ne so, non hanno accordi di sicurezza proattivi. Il repository ELPA GNU, d'altra parte, è gestito dall'FSF e ha pacchetti firmati che dovrebbero aiutare. Naturalmente, se la sicurezza è davvero importante, potresti voler rivedere e installare manualmente i pacchetti elisp invece di utilizzare il gestore pacchetti.
A mio avviso, alcuni repository hanno più spese generali di invio dei pacchetti rispetto ad altri; i repository con più sovraccarico tendono ad avere meno pacchetti. In ordine dal più al minimo sovraccarico:
Personalmente penso che MELPA Stable o Marmalade probabilmente vinceranno a lungo termine per la maggior parte degli utenti: il MELPA vero e proprio è piuttosto instabile e ELPA è troppo restrittivo per essere realmente scalabile per molti pacchetti. Ma questa è solo un'opinione.
Sono disponibili diversi repository di pacchetti.
Ufficiale
GNU ELPA è il repository di pacchetti ufficiale. È piccolo e richiede l'assegnazione del copyright (di tutti gli autori di un pacchetto) alla FSF per contribuire ad esso.
I pacchetti su GNU ELPA sono davvero solo un repository git . Il vantaggio di essere ospitati qui è che il core team prova ad aggiornare i pacchetti se Emacs stesso aggiunge o depreca funzionalità.
Costruito dalla fonte
MELPA è il repository di pacchetti più grande e in più rapida crescita . Rilascia una nuova versione ogni volta che una nuova versione viene trasferita in un repository o viene aggiornata una pagina EmacsWiki.
È all'avanguardia, ma in pratica funziona molto bene. MELPA è curata per evitare pacchetti duplicati e per garantire che venga registrata la sede canonica del pacchetto (anziché un fork casuale).
MELPA ha il problema che le versioni sono solo timestamp, ad es my-package-20131231.2359. Questo significa che se dipendi dal mio pacchetto:
;; Package-Requires: ((my-package "1.2.3"))
quindi Emacs penserà che qualsiasi versione su MELPA sia abbastanza nuova.
MELPA Stable è uguale a MELPA, ma anziché utilizzare le versioni datestamp, utilizza le versioni nei tag git. Ciò consente una migliore risoluzione delle dipendenze, ma presenta problemi con la dipendenza dai pacchetti wiki .
Caricamenti dell'utente
Marmalade è molto più simile a un repository tradizionale di altri linguaggi di programmazione. Lo sviluppatore del pacchetto carica il pacchetto su Marmalade quando rilasciano.
In linea di principio, ciò fornisce ai pacchetti un corretto processo di rilascio (Marmalade precede MELPA stabile) ed evita anche il problema del numero di versione generato automaticamente. Tuttavia, non esiste una verifica dell'identità. Chiunque può caricare un pacchetto, anche se non lo ha scritto. Questo diventa difficile se il manutentore my-packagerileva che qualcun altro ha caricato my-packagee non può successivamente caricare nuove versioni.
Marmalade era un'app node.js ed è ora scritta in elisp. Entrambe le versioni hanno avuto occasionalmente problemi di uptime.
progetto specifico
Org-mode ELPA è un repository che ospita solo orge org-plus-contrib. La modalità Org fa parte del core di Emacs, ma è sviluppata esternamente e il codice viene sincronizzato periodicamente con il trunk Emacs periodicamente. Questo repository ti consente di avere la modalità org all'avanguardia.
User42 ELPA è un repository per uno sviluppatore di pacchetti singoli che ha rilasciato una vasta gamma di pacchetti Emacs . Se ti piace uno dei suoi pacchetti, puoi aggiungere questo repository.
Sunrise Commander ELPA è un repository per estensioni per Sunrise Commander (un pacchetto Emacs per la ricerca di file, ispirato al comandante di mezzanotte).
Pensionato
ELPA di Tromey è stato il primo repo istituito. È ufficialmente sostituito con GNU ELPA, ma non aveva gli stessi requisiti di assegnazione del copyright. A partire dal 2010, non è più aggiornato.
L'archivio dei pacchetti Elpy conteneva vari pacchetti sviluppati da Jorgen Schaefer per "Elpy, l'Emacs Python Development Environment" , ma che è migrato a MELPA Stable.
no one has mentioned the risks involved in using github, a commercial provider of web based software, as a backend: ma sono sicuro che quelle preoccupazioni scompariranno ora che è Microsoft GitHub ;-)
Alcune informazioni aggiuntive, per integrare le altre risposte qui.
Alcune informazioni su MELPA e MELPA "stable" -
Inizia guardando questa domanda praticamente duplicata , da StackOverflow, inclusi i commenti per la domanda stessa. In particolare, questo commento che ho pubblicato, dopo lo scambio di e-mail con Donald Curtis (manutentore di MELPA e MELPA stabile):
Dal suo punto di vista [di Donald Curtis, e come ho capito la sua comunicazione con me], il sito MELPA "stabile" è solo in modalità di manutenzione . E l'unica ragione per cui non esiste un codice come il mio è che nessuno ha implementato il caricamento dal wiki [Emacs Wiki] per il sito "stabile". Inoltre, non esiste un "curating" fatto da nessuno - nessun filtro per determinare se un pacchetto è stabile, rischioso ecc. L'esistenza di due siti è stata richiesta da alcuni sviluppatori di pacchetti che volevano distinguere le versioni di sviluppo dei loro pacchetti da quelle precedenti ("stable ") versioni.
In sintesi, non c'è nulla che sia intrinsecamente più "stabile" nel contenuto di "MELPA stable" . La numerazione delle versioni e il metodo di alimentazione possono essere diversi; È tutto. E se un particolare manutentore del pacchetto vuole distinguere le versioni "stabili" dalle versioni "di sviluppo", e vuole farlo caricandole su due siti diversi, questo è l'effetto - per quel pacchetto .
Una differenza tra MELPA e Marmalade (e GNU ELPA) è che non è necessario che il codice che ha contribuito a MELPA provenga da un repository git. In particolare, può essere automaticamente estratto dall'area Elisp di Emacs Wiki .
Ciò significa, come alcuni hanno detto, che chiunque può caricare qualcosa e non hai modo di sapere se il codice è effettivamente dell'autore dichiarato, ecc.? Sì e no. In generale sì: chiunque è libero di caricare il codice Elisp su Emacs Wiki. Come dice la parte superiore della pagina Elisp-Area:
Questa è l'area elisp di EmacsWiki, dove raccogliamo i file EmacsLisp. Nessun login richiesto, nessun controllo versione richiesto, nessun ftp richiesto, nessuna password richiesta. È semplice come il wiki stesso. Ciò significa anche che chiunque può inserire codice dannoso in questi file EmacsLisp. In caso di dubbio, non usarli.
Tuttavia, solo per questo, sono un amministratore del wiki e le mie librerie Lisp nell'area wiki Elisp sono pagine bloccate. Ciò significa che solo un amministratore wiki può caricarli. Quindi, in questo caso, puoi essere abbastanza sicuro che le mie librerie che scarichi da MELPA o Emacs Wiki sono state caricate da me. Come per ogni cosa su Internet, tuttavia, non esiste una garanzia corazzata, così come non esiste una garanzia con il codice stesso. Come dice il blurb GPL in ogni libreria GPL:
Questo programma è distribuito nella speranza che possa essere utile, ma SENZA ALCUNA GARANZIA; senza nemmeno la garanzia implicita di COMMERCIABILITÀ o IDONEITÀ A UN PARTICOLARE SCOPO. Vedi la GNU General Public License per maggiori dettagli.
HTH. Happy hacking.