Perché e quando creare un pacchetto R?

Capisco che questa domanda sia piuttosto ampia, ma mi chiedo quali dovrebbero essere i punti decisivi nel decidere di creare (o meno) un nuovo pacchetto per R. Per essere più specifici, aggiungerei che la domanda non riguarda i motivi per usa R in sé, più sulla decisione di compilare vari script e di integrarli in un nuovo pacchetto.

Tra i punti che potrebbero portare a queste decisioni, ho pensato (in modo non esaustivo) a:

• la non esistenza di altri pacchetti nello stesso sottocampo;
• la necessità di scambiare con altri ricercatori e consentire la riproducibilità degli esperimenti;

E tra i punti che potrebbero portare a una decisione contraria:

• parte dei metodi utilizzati già presenti in alcuni altri pacchetti;
• numero di nuove funzioni non sufficienti per giustificare la creazione di un nuovo pacchetto indipendente.

Avrei potuto dimenticare molti punti che potrebbero rientrare in entrambi gli elenchi e, inoltre, questi criteri sembrano in parte soggettivi. Quindi, cosa diresti che dovrebbe giustificare e, a quel punto, iniziare a riunire varie funzioni e dati in un nuovo pacchetto documentato e ampiamente disponibile?

Non programmo in R, ma programmo diversamente e non vedo alcun problema specifico di R qui.

Immagino che la maggior parte delle persone scriva prima qualcosa perché la vogliono davvero per se stessi. Al contrario, qualsiasi sensazione che si dovrebbe pubblicare software perché è la cosa da fare dovrebbe essere fortemente contrastata. Le persone intelligenti possono essere pessimi programmatori e spesso lo sono.

Diventare pubblici sembra essere una questione di fiducia nel fatto che hai qualcosa di buono o migliore di ciò che è già pubblico e colma un vuoto. Sapere che altre persone vogliono fare la stessa cosa è sicuramente una spinta.

In caso di dubbi, non pubblicare. In molte comunità, esiste un problema di controllo di qualità di software mediocre o difettoso rilasciato da programmatori acritici o inesperti, sebbene quanto sia grave il problema rimane aperto al dibattito. Gli ottimisti ritengono che le curiosità possano essere semplicemente ignorate e che gli utenti esporranno bug e limitazioni abbastanza velocemente; i pessimisti sentono che stiamo affogando in cose di scarsa qualità ed è difficile distinguere i vincitori dai perdenti. (D'altra parte, l'esperienza acquisita dalla pubblicazione fa parte di ciò che consente ai programmatori di migliorare.)

Potrebbe esserci un libro su questo, ma alcuni suggerimenti vengono in mente:

1. La documentazione di buona qualità distingue un buon software e un buon codice, anzi a volte più ovviamente. Non sottovalutare mai quanto lavoro sarà necessario per fornire la documentazione che il codice merita. I programmatori R sembrano spesso richiedere agli utenti R di sapere esattamente quello che fanno sulla tecnica implementata e documentare minimamente ....

2. Per quanto possibile, prova il tuo codice in modo da poter riprodurre le soluzioni pubblicate con dati reali da altre parti. (Se stai codificando qualcosa di totalmente nuovo, potrebbe essere più difficile, ma non impossibile. Inoltre, potresti trovarti spesso a chiederti se si tratti del loro bug o del tuo.)

3. I programmatori spesso sottovalutano la capacità degli utenti di lanciare dati non adatti a un programma. Quindi, pensa a cosa potrebbe andare storto, ad es. Con valori mancanti, zeri se un programma assume un valore positivo, ecc. Ecc. (Il punto positivo qui è che è compito degli utenti trovare i problemi e migliorare il codice attraverso il loro feedback , ma un programma che si interrompe facilmente non migliorerà la tua reputazione.)

Questa è una domanda importante e pratica. Iniziamo distinguendo tra la scrittura di un pacchetto e la sua pubblicazione su CRAN.

Motivi per non scrivere un pacchetto:

• Efficienza dei costi.
• Mancanza di esperienza.

Motivi per scrivere un pacchetto R:

• Condivisione con persone e piattaforme.
• Forza un codice ordinato e un processo di lavoro.
• Facilità d'uso (anche per sé) quando le funzioni iniziano ad accumularsi.

Motivi per inviare un pacchetto (CRAN, Bioconduttore, ...):

• Contributo alla comunità.
• Facilità di distribuzione.

Ricorda che esiste l'opzione n. 3; puoi chiedere al manutentore di un pacchetto rilevante di includere il tuo codice o i tuoi dati.

I miei trigger personali per l'imballaggio sono:

• Trovo che sto usando di nuovo del codice che ho scritto una volta per un altro progetto di analisi dei dati.
• Penso che avrò bisogno del metodo che ho appena scritto di nuovo.

• Un collega mi chiede un codice. Una parte sostanziale del codice che scrivo è almeno tanto su richiesta dei colleghi (che usano R ma non programmano tanto se stessi) quanto per me.

• Uso i requisiti formali di un pacchetto (documentazione) per "costringermi" a ripulirmi e documentare il mio codice.

Sono d'accordo con @JohnRos che esiste una differenza sostanziale tra la scrittura di un pacchetto e la pubblicazione del pacchetto.

• Di solito impacco in anticipo, ma poi rendo il pacchetto solo "semipubblico". Cioè, potrebbe essere disponibile su un server interno (o su r-forge), in modo che i miei colleghi possano accedere al pacchetto. Ma pubblico su CRAN solo dopo che il pacchetto è stato utilizzato per mesi o addirittura alcuni anni da colleghi intimi. Questo non fa apparire tutti i bug secondo il punto 3 di @Nick Cox, ma una discreta quantità di essi.
  Le versioni del pacchetto (ho inserito la data dopo il trattino nel numero di versione) rendono facile risolvere le cose ("per fare questo e quello, assicurati di installare almeno la versione della scorsa settimana")

• Secondo il mio contratto di lavoro, il mio datore di lavoro ha l'ultima parola sulla decisione se e come un pacchetto possa essere pubblicato nel mondo esterno.

La cosa in cui non ho ancora una buona strategia per il packaging sono i dati.

Commenti al tuo elenco di motivi:

• la non esistenza di altri pacchetti nello stesso sottocampo;

Non trovare un pacchetto che fa ciò di cui ho bisogno per me fa scattare la scrittura del codice, ma non ha a che fare con la decisione se impacchettare o meno.

• la necessità di scambiare con altri ricercatori e consentire la riproducibilità degli esperimenti;

Definitivamente. Forse già la necessità di condividere tra diversi computer che uso.

E tra i punti che potrebbero portare a una decisione contraria:

• parte dei metodi utilizzati già presenti in alcuni altri pacchetti;

potresti importare questi metodi nel tuo pacchetto / codice: questo è un punto contro la scrittura di tale codice, ma ha solo indirettamente a che fare con il packaging.

• numero di nuove funzioni non sufficienti per giustificare la creazione di un nuovo pacchetto indipendente.

Per me, non esiste un numero minimo di funzioni per avviare un pacchetto. Nella mia esperienza i pacchetti tendono a crescere "automaticamente". Al contrario, dopo che mi sono ritrovato a ramificare alcune volte un nuovo pacchetto da un altro (perché ad esempio alcune funzioni di supporto alla fine si sono rivelate tematicamente diverse e utili anche in altre situazioni), ora sono piuttosto creando immediatamente nuovi pacchetti.

Inoltre, se non hai scritto documentazione e test, questo può essere un lavoro proibitivo quando si accumula un numero "sufficiente" di funzioni per la creazione di un pacchetto.
(Se li scrivi immediatamente, lo sforzo aggiuntivo di metterlo in un pacchetto è trascurabile una volta che conosci il flusso di lavoro).

Direi di creare un pacchetto ogni volta che stai facendo un insieme abbastanza grande di attività simili in R che trarrai vantaggio da un pacchetto in cui puoi mettere cose in uno spazio dei nomi (per evitare conflitti con funzioni con nomi simili), dove puoi scrivere documentazione. Ho anche un pacchetto su github per raggruppare un sacco di funzioni non correlate, ma lo uso così spesso che pensavo meritassero documentazione, file man, ecc.

Un altro caso d'uso potrebbe essere l'invio di un documento, se si dispone di una serie di funzioni, è possibile creare facilmente un pacchetto, compresa la documentazione per tali funzioni, esempi per ciascuna funzione e un'esercitazione su come utilizzarlo. E non è necessario metterlo su CRAN, come detto nelle risposte sopra. Questo potrebbe essere fantastico per la riproducibilità.

Tre strumenti che direi sono importanti:

• devtools pkg , per rendere super facile la creazione di pacchetti (vedere anche il wiki sulle pagine github di devtools
• roxygen2 pkg , per semplificare la scrittura della documentazione per il pacchetto
• GitHub, puoi usare install_github(o similmente install_bitbucket, ecc.) Per installare direttamente da GitHub, che è bello da condividere con gli altri.

Sono d'accordo con tutto ciò che ho letto finora. Tutti questi motivi sono buone prassi di programmazione e non si applicano in particolare a R. Tuttavia mi ritrovo a scrivere pacchetti R per la maggior parte del tempo, e per l'ennesima ragione. Quindi aggiungerò:

Motivo specifico di R per scrivere un pacchetto R:

• perché scrivi in ​​C.

Ogni volta che usi lingue straniere come C, C ++ o FORTRAN (principalmente per il calcolo ad alte prestazioni), scrivere un pacchetto vale in gran parte il problema. Se hai più di una o due funzioni, finisci rapidamente con i file in tutto il luogo e le dipendenze tra il codice R e C che è difficile da mantenere e da portare.

Una ragione non menzionata nelle altre risposte eccellenti: hai un progetto di analisi dei dati ampio o complesso. Comprimendo, prima di tutto, i dati come pacchetto, quindi estendendoli con utili funzioni per trasformare, tracciare o calcolare analisi specifiche. In questo modo si ottiene una versione documentata dei dati completa di tutte le funzioni utilizzate per calcolare l'analisi riportata. Quindi i report del progetto possono essere scritti usando knitr o altri pacchetti per ricerche riproducibili!

Ciò potrebbe far risparmiare tempo in modo significativo se fosse necessario eseguire una nuova analisi o potrebbe anche essere pubblicato (o semipubblicato) se l'analisi fosse pubblicata.