Considerazioni tecniche per i manutentori del pacchetto di non utilizzare il gestore pacchetti Emacs?

Sto notando che alcuni importanti manutentori dei pacchetti stanno scegliendo di non utilizzare il sistema di gestione dei pacchetti Emacs (ESS?) O si lamentano delle sue limitazioni (Helm).

Citando Helm 's README.md :

ATTENZIONE : a causa di un cattivo concetto di package.el che si occupa di recuperare i file helm e compilarli, gli utenti hanno avuto errori la maggior parte delle volte durante l'aggiornamento da melpa e list-package. Per evitare ciò, Async è stato aggiunto come dipendenza da helm per forzare package.el compilando i suoi file in un ambiente pulito. Le persone che installano da git e usano il file make non soffriranno di questo problema e non avranno bisogno di Async sebbene sia raccomandato in quanto corregge l'installazione di tutti gli altri pacchetti che è possibile installare con package.el da (m) elpa. Vedi le FAQ per maggiori informazioni.

Quali limiti tecnici esatti ha l'attuale sistema di gestione dei pacchetti a cui potrebbero alludere, e perché i pacchetti dovrebbero usare asynccome dipendenza?

package package-repositories ess

— Amelio Vazquez-Reina
fonte

Questa domanda dovrebbe essere chiusa come troppo ampia per questo sito, penso. È più mirato a un forum di discussione. Prova help-gnu-emacs@gnu.org o emacs-devel@gnu.org o Emacs reddit o alcuni di questi. " Qual è esattamente il problema? " Presuppone che esista uno di questi problemi e chiedersi quali siano i possibili problemi per qualsiasi pacchetto (o qualsiasi manutentore del pacchetto) è troppo ampio.

— Estratto il

ESS è ospitato su Melpa: melpa.org/#/ess , forse è solo una questione di documentazione. Conosco molti progetti, che in genere sono installabili tramite un gestore di pacchetti di sistema, ma scelgono di non menzionare questa opzione senza motivo reale (forse supponendo che se si è arrivati al download dei sorgenti / binari dal sito, è necessario disporre di un motivo per farlo). Non so quale problema avesse Helm.

— wvxvw,

Il tuo titolo mi sembra un po 'strano. Intendevi scrivere "manager" due volte o intendevi manutentori?

— Malabarba,

Scrivendo come sviluppatore ESS, facci sapere come possiamo migliorare le cose - come altri hanno commentato, ESS è in MELPA.

— Stephen Eglen,

Risposte:

Il problema a cui ti riferisci è probabilmente che quando aggiorni un pacchetto all'interno di una sessione Emacs in cui quel pacchetto è già in uso, la vecchia versione del pacchetto a volte interferisce durante la compilazione della nuova versione, portando a file non compilati.

C'è una soluzione provvisoria per quello in Emacs-25, ma AFAIK il problema è ancora presente in 24.5.

— Stefan
fonte

Con la notevole eccezione di ProofGeneral, non sono a conoscenza dei principali pacchetti Emacs che non sono disponibili in alcuni archivi ELPA. In particolare, ESS è in MELPA da tre anni . E PG è una storia a sé stante e sicuramente non rappresentativa dell'intero ecosistema Emacs.

L'ELPA ha sicuramente i suoi difetti, ma per la stragrande maggioranza dei pacchetti funziona perfettamente, anche per quelli di grandi dimensioni come Magit. Helm è l'unico pacchetto che vedo lamentarsi di ELPA. Non sono sicuro di cosa si lamentino esattamente, ma immagino si tratti di compilazione:

Durante gli aggiornamenti Emacs compila la nuova versione del pacchetto in un ambiente in cui è ancora caricata la versione precedente. Normalmente, questo non fa affatto male, ma può rompere le macro in determinate situazioni. Emacs compilerà la nuova versione rispetto alla vecchia implementazione della macro, che può causare la rottura se il nuovo codice si basa su una modifica specifica in quella macro.

Essendo anch'io un manutentore del pacchetto, non sono affatto d'accordo con questa affermazione. Tendo a incolpare Helm piuttosto che ELPA o Emacs. A mio avviso, l'affermazione è iperbole e il problema, ma è un sintomo di macro con uso eccessivo e ab.

Se usi molte macro e, ancora peggio, inserisci un codice non banale nel corpo delle macro, devi semplicemente essere consapevole delle implicazioni che ciò ha per la compilazione dei byte e devi stare attento a mantenere la retrocompatibilità con le tue macro nel tuo pacco. Non farlo, e invece passare la colpa in giro, non è una cosa molto bella da fare. I miei 2 centesimi.

— lunaryorn
fonte

FWIW, non sono d'accordo con il tuo disaccordo: mentre concordo sul fatto che è meglio cercare di evitare l'uso eccessivo di macro, i problemi di compilazione sono reali e possono influenzare più delle chiamate macro (ad esempio, possono essere attivati anche da funzioni inlinabili o da funzioni chiamate durante la macro-espansione). E quando vieni morso da questo problema, i tuoi file .elc sono errati e possono comportarsi in modo errato in tutti i tipi di modi interessanti, quindi può essere difficile diagnosticare il problema e risolverlo richiede la disinstallazione + reinstallazione del pacchetto (una volta che hai capito il problema e quale pacchetto deve essere reinstallato.

— Stefan

@Stefan Non nego i problemi di compilazione. Mi sono morso da solo. Ma non mi piace l'atteggiamento che traspare da questa affermazione e la mancanza di quello che definirei un "punto di vista equilibrato". Helm viene morso così male perché hanno fatto anche molti errori dalla loro parte, ma la loro affermazione non lo riconosce. Secondo la mia modesta opinione, chiamare funzioni nel corpo macro è un tale errore. Le macro sono solo per la sintassi, ma mai per funzionalità. Ma capisco che questo sembra essere un argomento su cui la comunità di Emacs Lisp ha molte opinioni diverse.

— lunaryorn,

ropemacs , jdee-emacs ed excorporate sono pacchetti notevoli che non si trovano in alcun archivio ELPA (a seconda dei criteri per i pacchetti principali). Tuttavia, la stragrande maggioranza dei pacchetti lo è.

— Wilfred Hughes,