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).