Buone pratiche relative a più sistemi di gestione dei pacchetti

Alcuni linguaggi di programmazione sono dotati di un proprio sistema di gestione dei pacchetti, ad esempio, nel caso di R, il install.packagescomando integrato si installa dal repository CRAN e si occupa delle dipendenze.

Parallelamente, il sistema operativo viene fornito con i propri sistemi di gestione dei pacchetti, come il aptcomando per le distribuzioni Linux basate su debian.

Avevo deciso che era meglio usare il gestore dei pacchetti della distribuzione, al fine di garantire che tutto sul mio sistema fosse compatibile (vedi /programming//a/31293955/1878788 ).

Ma presto venne un giorno in cui avevo bisogno di cose che non erano disponibili in questo modo. Ad esempio, un programma di bioinformatica che non è stato impacchettato dalla mia distribuzione richiederebbe una versione specifica di R. È successo che il programma era disponibile attraverso un progetto chiamato "bioconduttore", il cui obiettivo era fornire pacchetti R per bioinformatica, assicurando che i pacchetti essere compatibili tra loro (vedi https://www.bioconductor.org/install/#why-biocLite ).

Così ho deciso di non utilizzare il mio sistema di gestione degli imballaggi del sistema operativo per R e di installare tutto tramite il biocLitecomando fornito dal progetto bioconduttore.

Questo approccio ha funzionato senza intoppi per qualche tempo, fino a quando ho scoperto che per mantenere ecosistemi bioinformatici coerenti, sani e facilmente ricostruibili, alcune persone avevano deciso di utilizzare il sistema di gestione dei pacchetti conda. Questo progetto, chiamato "bioconda" fornisce non solo pacchetti R, ma cose di ogni sorta di lingue, con la possibilità di cambiare facilmente versione e così via (vedi https://bioconda.github.io/ ).

Ho quindi deciso di utilizzare questo approccio invece, e ha funzionato senza intoppi fino a quando non ho avuto bisogno di un pacchetto R che non era fornito da bioconda / conda. È presumibilmente super facile, ma i miei tentativi di creare un pacchetto conda sono falliti, quindi ho provato a installare il pacchetto utilizzando il metodo bioconduttore e non è riuscito di nuovo. Ho l'impressione che in qualche modo l'installazione sbagliata di R sia stata utilizzata dai meccanismi di costruzione del pacchetto. Così ho deciso di cancellare la mia installazione di conda (ancora molto giovane) e tornare al mio ecosistema di bioconduttori.

Mi chiedo per quanto tempo dovrò saltare da un approccio all'altro. Esistono buone pratiche generali su come gestire questi livelli multipli, interferenti e sovrapposti di gestione dei pacchetti?

Modifica (14/09/2017) : Un'altra opzione che ho preso in considerazione è l'uso di gestori di pacchetti alternativi a livello di sistema operativo, come Guix o Nix .

Non sono sicuro di ciò che è disponibile per R (sentito parlare di REnv), ma per Python ho deciso sull'approccio pragmatico che ogni utente è responsabile del proprio ambiente Python con pyenv(lo stesso vale per Perl con perlbrewe Ruby con RVM). In questo modo, gli utenti possono creare il proprio ambiente ottimale per ogni progetto senza la mia assistenza ( pyenvgestisce le installazioni di Python e quindi è possibile utilizzare pipper installare moduli locali per quella specifica installazione di Python).

I pacchetti di sistema vengono utilizzati solo per esigenze di sistema.

Di solito è meglio usare il gestore di pacchetti di sistema. Ma se usi linguaggi moderni, i distributori veloci e stabili non includeranno nuovi pacchetti e versioni. E i pacchetti non così popolari non possono mai essere inclusi nei repository.

Quindi direi che il modo migliore in quel caso è usare le funzioni integrate del linguaggio. Se R-creators creerà uno strumento ufficiale per la gestione dei pacchetti, sarebbe fantastico, ma l'uso di strumenti non ufficiali è alquanto rischioso.