2012-01-14 19 views
19

Sto sviluppando un framework per il calcolo riproducibile con R. Un problema con cui sto combattendo è che qualche codice R potrebbe funzionare perfettamente nella versione XY-Z di un pacchetto, ma poi perché provi a riprodurlo 3 anni dopo, i pacchetti sono stati aggiornati, alcune funzioni sono cambiate e il codice non viene più eseguito. Questo problema riguarda anche i documenti Sweave che usano i pacchetti.Come installare e gestire molte versioni di pacchetti R

L'unico modo per riprodurre i risultati in modo sicuro consiste nell'installare la versione R e la versione dei pacchetti utilizzati dall'autore originale. Se si trattasse di un singolo caso, si potrebbero estrarre gli archivi CRAN e installare le versioni appropriate. Ma per il mio framework questo non è pratico e ho bisogno di avere le versioni del pacchetto preinstallate.

Assumiamo per ora che mi limito a una singola versione di R, ad es. 2.14. Quale sarebbe un modo pratico per installare molte versioni di pacchetti R, in modo che io possa caricarli al volo? Suppongo di poter fare qualcosa come creare directory di librerie separate per ogni versione di ogni pacchetto e quindi utilizzare gli argomenti personalizzati di lib.loc durante il caricamento. Sarà comunque complicato. Qualche consiglio o tentativo precedente di fare qualcosa di simile?

Il mio framework gira su server Ubuntu.

+0

Conoscete dev_mode nel pacchetto devtools? IIRC sta affrontando un problema simile. – baptiste

+0

Non proprio. Cambia solo il tuo libpath in una directory temporanea sandbox. Ma non fornisce alcun sistema oltre a quello. – Jeroen

+0

È un duplicato. Vedere la mia risposta qui: http://stackoverflow.com/questions/8343686/how-to-install-2-different-r-versions-on-debian/8343739#8343739 – Oz123

risposta

4

È possibile installare pacchetti con versioni (ad esempio, rinominare nella directory foo_1.0 anziché foo) e collegare le versioni di cui si desidera ricreare una data snapshot di pacchetti R + in una libreria. Ovviamente, i pacchetti potrebbero effettivamente vivere in un albero separato, quindi potresti avere library.projectX/foo ->library.all/foo/1.0.

+0

Inoltre, è possibile modificare la variabile di ambiente R_LIBS nella directory appropriata per quel progetto. –

-1

Vorrei provare a modificare il file DESCRIPTION e modificare il campo "Pacchetto" lì aggiungendo il numero di versione.

Ad esempio, si scarica la fonte del pacchetto a dalla pagina CRAN (http://cran.r-project.org/web/packages/pls/). Scompattare il file compresso (pls_2.3-0.zip) in una directory ("pls /"). I seguenti passi sono di cambiare il nome del pacchetto in DESCRIPTION ("pls/DESCRIPTION") e l'installazione con il comando R 'R CMD INSTALL pls /', dove 'pls /' è un percorso per l'origine del pacchetto con il file DESCRIPTION modificato.

Giocare con i percorsi di libreria R mi sembra una cosa pericolosa.

+5

Giocare con i nomi dei pacchetti è ancora più pericoloso perché si rompono tutte le dipendenze. I percorsi della libreria sono progettati per essere riprodotti con nomi di pacchetti diversi. –

1

Il sistema operativo offre ancora più handle per la separazione completa e lo stack Debian/Ubuntu come una tonnellata di quelli disponibili. Due con cui ho giocato sono

  • ambienti chroot: lo usiamo per completare gli ambienti di compilazione separati dalle macchine host. Ad esempio, tutti i caricamenti Debian che ho prodotto sono costruiti in un chroot pbuilder i386 ospitato sul mio server Ubuntu di amd64. Chroot è una chiamata di sistema Unix molto potente. Chroot, e in particolare il sistema pbuilder costruito su di esso (per la creazione di pacchetti Debian) sono pensati per operare senza testa.

  • Macchine virtuali: questo ti dà tutta la generalità. La mia scatola non così potente gestisce facilmente tre macchine virtuali: Debian i386, Ubuntu i386 e Windoze XP. Per questo, attualmente uso KVM insieme a libvirt; questo è specifico per Linux. Ho anche usato VirtualBox e VMware in passato.

Problemi correlati