sfondo

Uso emacs ogni giorno, ma soprattutto per fare le cose. Non mi piace molto personalizzarlo più che aggiungere pacchetti e non mi piace la risoluzione dei problemi. Voglio che emacs svanisca sullo sfondo come fa un buon sistema operativo e vada avanti con le cose. Qualche tempo fa ho scoperto che el-getmi permetteva di installare i pacchetti di cui avevo bisogno che non erano disponibili package.ele mi ha anche dato un maggiore controllo come la selezione del maintramo della modalità Org piuttosto che il bordo di spurgo che può causare problemi temporanei. Ora non sono sicuro se dovrei usare el-geto meno.

Domanda

el-getsembrava essere un'ottima soluzione per i vari repository e gli hack di emacs là fuori. Offriva funzionalità che semplicemente non erano possibili package.el. Ora che package.elnelle versioni più recenti di emacs ( >=24.4) supporta più repository, quali sono i casi d'uso el-gete le alternative simili al gestore pacchetti integrato di emacs?

Ci sono cose che sono ancora impossibili con ELPA, e ci sono cose che saranno sempre impossibili con ELPA, perché non si adattano al concetto di ELPA: non sarai mai in grado di installare un commit specifico dal suo hash da un fork repository. Allo stesso modo, non sarai mai in grado di applicare patch locali personalizzate a un pacchetto prima di installarlo. Queste funzionalità vanno semplicemente oltre lo scopo di ELPA e, se ne hai bisogno, dovrai utilizzare un gestore di pacchetti alternativo.

Penso, tuttavia, che al giorno d'oggi el-get sia una specie di soluzione legacy. Dato che ELPA è diventato di fatto il gestore di pacchetti standard per Emacs, i gestori di pacchetti alternativi dovrebbero integrarsi perfettamente con ELPA. el-get, tuttavia, non espone i propri pacchetti a ELPA, il che significa che i suoi pacchetti sono completamente invisibili a ELPA e i pacchetti ELPA non possono mai dipendere dai pacchetti el-get, con ovvie implicazioni per la gestione delle dipendenze.

Se hai bisogno di funzionalità oltre a ELPA, dovresti oggi guardare QUELPA piuttosto che el-get.

Ho scritto un nuovo gestore di pacchetti per Emacs straight.el, che tenta di migliorare tutte le soluzioni di gestione dei pacchetti esistenti. C'è una vasta sezione nella straight.eldocumentazione sui confronti con altri gestori di pacchetti , ma ecco un breve riassunto:

• package.elscarica tarball opachi dai server centrali, senza possibilità di selezionare una versione specifica di un pacchetto e non consente di apportare modifiche locali ai pacchetti; contribuire alle modifiche a monte è impossibile. straight.elclona i repository Git in modo decentralizzato (ma utilizza automaticamente ricette di MELPA , GNU ELPA ed EmacsMirror , se lo desideri) e ti consente di apportare modifiche locali arbitrarie a tali dati, eseguire il commit di tali modifiche e contribuire a monte. Questo può essere fatto manualmente oppure è possibile utilizzare le operazioni integrate di gestione del repository di massa. Le modifiche ai pacchetti vengono rilevate automaticamente e non sono necessarie ricostruzioni manuali. Inoltre,straight.el supporta la completa riproducibilità per la configurazione di Emacs, poiché consente di scrivere un file di blocco di revisione che include gli hash Git di tutti i pacchetti.
• Quelpa e Cask sono entrambi basati su package.eled ereditano molti degli stessi svantaggi. Ad esempio, Cask non ha alcun concetto di installazione di una particolare versione di un pacchetto. Quelpa lo fa, ma richiede che tu abbia codificato l'hash Git nel tuo file init. straight.elevita del package.eltutto, sostituendo tutte le sue funzionalità principali con un design unificato su misura per molti più casi d'uso.
• el-get ha il vantaggio di poter installare pacchetti da qualsiasi luogo (tutti i sistemi di controllo versione conosciuti, HTTP arbitrario, gestori di pacchetti di sistema, EmacsWiki, persino go get!?). Tuttavia, supportando così tante fonti, el-get non può fornire il tipo di operazioni avanzate di gestione dei pacchetti (come la riproducibilità tramite lockfile di revisione e operazioni interattive di gestione dei repository) che straight.elfornisce. straight.elsupporta solo Git, poiché la maggior parte dei pacchetti sono disponibili tramite Git e quelli che non lo sono possono essere ottenuti tramite EmacsMirror (ti sfido a trovarne uno che non può essere!). Si noti straight.eltuttavia che fornisce un'API estensibile per ulteriori backend di controllo versione (ad es. Mercurial) da aggiungere in futuro, se lo si desidera.
• Borg ha una filosofia molto simile straight.ele offre molti degli stessi vantaggi. Tuttavia, non è progettato per essere un gestore di pacchetto completo, ed è progettato per essere utilizzato nella preoccupazione con altri strumenti come epkg, auto-compilee Magit. Al contrario, straight.elè autonomo e offre tutto ciò di cui hai bisogno da solo, richiedendo poca o nessuna configurazione aggiuntiva. Inoltre, Borg utilizza i sottomoduli Git, la cui interfaccia ha dei bordi grezzi, mentre straight.elutilizza repository Git gestiti in modo indipendente, offrendo ulteriore flessibilità e potenza.
• C'è anche l'approccio manuale, ma non lo consiglio. Dopo i primi due mesi, avresti reinventato Borg. Poi, dopo un paio di mesi, ti saresti reinventato straight.el. Imparerai molto sulla gestione dei pacchetti, però;)

Mentre ci sono pro e contro, penso che el-get sia ancora rilevante, nonostante le forti opinioni di @lunaryon (rejeep troppo).

Ho usato raw package.el con use-package per un po '(da 2 a 3 anni), poi sono passato a el-get , quindi a Cask . Sono tornato a el-get pochi giorni fa. Precedenti package.el , come molti altri, gestivo manualmente i componenti aggiuntivi.

Perché sono tornato a el-get ? Ho incontrato alcune stranezze di Cask su qualcosa che non è un repository git (un mio pacchetto Github che non è in MELPA), mentre quel pacchetto utilizza effettivamente git ... Non mi sono preoccupato di investigare o creare un biglietto, ho appena estratto il mio vecchio el-get config ed ero bravo ad andare in men che non si dica.

Poche cose che mi piacciono di el-get :

• Supporta più fetcher, non solo git.
• Contiene abbastanza ricette predefinite
• Più veloce di Cask all'avvio.
• e sì, @lunaryorn, il Wiki non è un posto dove distribuire codice, tuttavia non voglio creare un repository Github se non c'è clone su emacsmirror (Github).
• Autonomo, con Cask hai bisogno di un'installazione esterna. Uso un singolo file init (non una configurazione modulare) con modalità allout per navigare attraverso le sezioni.
• el-get è abbastanza semplice dal punto di vista dell'utente.

Nota: sto eseguendo Emacs Git HEAD su OSX e Linux.

Potresti voler dare un'occhiata paradox. Non è un altro gestore di pacchetti, ma un front-end più ordinato per package.el. Ad esempio, quando si aggiornano i pacchetti, viene richiesto se si desidera installarli ed eliminare quelli vecchi in un solo passaggio.

Se lo si utilizza, probabilmente si vuole insieme paradox-execute-asynchronouslya tnel file init.