2012-09-20 14 views
5

Sto scrivendo un protocollo per un'analisi riproducibile utilizzando un pacchetto interno "MyPKG". Ogni utente fornirà i propri file di input; oltre agli input, le analisi dovrebbero essere eseguite nelle stesse condizioni. (ad esempio, in modo che possiamo dedurre che i diversi risultati sono dovuti a diversi file di input).Come posso garantire un ambiente R coerente tra diversi utenti sullo stesso server?

MyPKG è in fase di sviluppo, pertanto library(MyPKG) caricherà l'ultima versione che l'utente ha compilato nella libreria locale. Inoltre caricherà tutte le dipendenze trovate nelle loro librerie locali.

Ma voglio che tutti utilizzino una versione specifica (MyPKG_3.14) per questa analisi pur consentendo lo sviluppo di versioni più recenti. Se ho capito bene, "R --vanilla" caricherà le stesse dipendenze per tutti.

Una volta terminato, salveremo l'ambiente di lavoro come VM per mantenere un ambiente riproducibile stabile. Quindi una soluzione temporanea (6 mesi) sarà sufficiente.

Ho escogitato due soluzioni potenziali, ma non sono sicuro che sia sufficiente.

  1. chiedere l'amministratore server per installare MyPKG_3.14 nel percorso predefinito R e quindi fornire il seguente codice nel protocollo:

    R --vanilla 
    library(MyPKG) 
    .... 
    

    o

  2. compilazione MyPKG_3.14 in un biblioteca specifica, ad es lib.loc = "/home/share/lib/R/MyPKG_3.14", e quindi fornire

    R --vanilla 
    library(MyPKG) 
    

  • Sono entrambi questi approcci sufficienti per garantire che tutti sono in esecuzione il stessa versione?
  • Uno è preferibile all'altro?
  • Ci sono altri problemi che potrebbero sorgere?
  • Esiste un'opzione preferita per la standardizzazione delle analisi multiple?
  • Devo includere un test dell'uscita di SessionInfo()?
  • Sarebbe meglio creare un unico account sul server che tutti possano usare?
+0

Ottima domanda. Sto lavorando su questo problema come parte di un progetto più ampio e ho in programma di rilasciare una libreria che genererà tracce di provenienza dopo ogni esecuzione. Sarebbe facile confrontare due tracce e vedere se la differenza sono solo nuovi dati o nuove librerie e si potrebbe modificare se necessario se si presentano risultati diversi. Mandami una email per maggiori dettagli. – Maiasaura

+0

@Maiasaura Non vedo la tua email. Inizia con kram? –

+0

si. berkeley dot edu – Maiasaura

risposta

1

paio di punti:

  • utilizzare le installazioni a livello di sistema dei pacchetti, per esempio il binario Debian/Ubuntu per R (incluse le porte CRAN) proverà a utilizzare /usr/local/lib/R/site-library (che gli utenti possono installare anche se aggiunto al gruppo proprietario della directory). In tal modo, tutti ricevono la stessa versione
  • Utilizzare la configurazione a livello di sistema, ad es. preferire $R_HOME/etc/ sopra i dotfiles sotto ~/. Per lo stesso motivo, il pacchetto Debian/Ubuntu offre i softlink in /etc/R/
  • Utilizzare i servizi di R per interrogare i pacchetti (ad esempio installed.packages()) per segnalare pacchetti e versioni.
  • Utilizzare, se disponibili, le funzioni a livello di sistema operativo per eseguire query sul rilascio e sulla versione del sistema operativo. Questo, tuttavia, è meno standardizzato.

Per quanto riguarda l'ultimo punto la mia scatola a casa dice

> [email protected]:~$ lsb_release -a | tail -4 
> Distributor ID: Ubuntu 
> Description: Ubuntu 12.04.1 LTS 
> Release:  12.04 
> Codename:  precise 
> [email protected]:~$ 

che è un inizio.

+0

+ 1 consiglio molto utile che mi hai dato di recente per rimuovere "~/R/x86_64-pc-linux-gnu-library/2.15" – GSee

Problemi correlati