Por que e quando criar um pacote R?

Entendo que essa questão é bastante ampla, mas me pergunto quais devem ser os pontos decisivos na decisão de criar (ou não) um novo pacote para R. Para ser mais específico, acrescentaria que a questão não é sobre os motivos para use R em si mesmo, mais sobre a decisão de compilar vários scripts e integrá-los em um novo pacote.

Entre os pontos que poderiam levar a essas decisões, pensei (de uma maneira não exaustiva) em:

• a inexistência de outros pacotes no mesmo subcampo;
• a necessidade de intercambiar com outros pesquisadores e permitir a reprodutibilidade de experimentos;

E entre os pontos que podem levar a uma decisão contrária:

• parte dos métodos usados ​​já presentes em alguns outros pacotes;
• número de novas funções insuficientes para justificar a criação de um novo pacote independente.

Eu poderia ter esquecido muitos pontos que poderiam constar de qualquer uma das listas e também esses critérios parecem parcialmente subjetivos. Então, o que você diria que deveria justificar e em que momento começar a reunir várias funções e dados em um novo pacote documentado e amplamente disponível?

Não programa em R, mas em contrário, não vejo nenhum problema específico de R aqui.

Eu imagino que a maioria das pessoas primeiro escreve algo porque realmente o quer por si. Por outro lado, qualquer sentimento de que alguém deva publicar um software, porque é o que deve ser feito, deve resistir fortemente. Pessoas inteligentes podem ser péssimas programadoras, e geralmente são.

Tornar-se público parece uma questão de ter certeza de que você tem algo tão bom ou melhor do que o que já é público e preenche uma lacuna. Saber que outras pessoas querem fazer a mesma coisa é certamente um impulso.

Se você estiver em dúvida, não publique. Em muitas comunidades, existe um problema de controle de qualidade de software medíocre ou com erros, lançado por programadores acríticos ou inexperientes, embora o quão ruim seja o problema permaneça aberto ao debate. Os otimistas acham que as trivialidades podem ser ignoradas e que os usuários expõem erros e limitações com rapidez suficiente; os pessimistas sentem que estamos nos afogando em coisas de baixa qualidade e é difícil diferenciar os vencedores dos perdedores. (Por outro lado, a experiência adquirida com a publicação faz parte do que permite aos programadores melhorar.)

Pode haver um livro sobre isso, mas alguns indicadores vêm à mente:

1. A documentação de boa qualidade distingue bom software e bom código, algumas vezes de maneira mais óbvia. Nunca subestime quanto trabalho será necessário para fornecer a documentação que o código merece. Os programadores de R geralmente parecem exigir que os usuários de R saibam o que sabem sobre a técnica que está sendo implementada e documentem minimamente ...

2. Na medida do possível, teste seu código para poder reproduzir soluções publicadas com dados reais de outros lugares. (Se você está codificando algo totalmente novo, isso pode ser mais difícil, mas não impossível. Além disso, muitas vezes você se pergunta se o bug é dele ou seu.)

3. Os programadores geralmente subestimam a capacidade dos usuários de lançar dados inadequados em um programa. Então, pense sobre o que poderia dar errado, por exemplo, com valores ausentes, zeros se um programa assume positivo, etc. etc. (a opinião benéfica aqui é que é tarefa dos usuários encontrar os problemas e melhorar o código através de seus comentários. , mas um programa que se decompõe facilmente não aprimora sua reputação.)

Esta é uma questão importante e prática. Vamos começar distinguindo entre escrever um pacote e publicá-lo no CRAN.

Razões para não escrever um pacote:

• Eficiência de custos.
• Falta de experiência.

Razões para escrever um pacote R:

• Compartilhando com pessoas e plataformas.
• Força um código organizado e um processo de trabalho.
• Facilidade de uso (mesmo para si mesmo) quando as funções começam a se acumular.

Razões para enviar um pacote (CRAN, Biocondutor, ...):

• Contribuição para a comunidade.
• Facilidade de distribuição.

Lembre-se de que existe a opção 3; você pode solicitar ao mantenedor de um pacote relevante que inclua seu código ou dados.

Meus gatilhos pessoais para embalagem são:

• Descobri que estou novamente usando algum código que escrevi para outro projeto de análise de dados.
• Acho que vou precisar do método que acabei de escrever novamente.

• Um colega me pede código. Uma parte substancial do código que escrevo é pelo menos tanto a pedido dos colegas (que usam R, mas não programam tanto eles mesmos) quanto a mim.

• Eu uso os requisitos formais de um pacote (documentação) para me forçar a limpar e documentar meu código.

Concordo com o @JohnRos que há uma grande diferença entre escrever um pacote e publicá-lo.

• Normalmente, empacotei com antecedência, mas depois tornei o pacote apenas "semipúblico". Ou seja, ele pode estar disponível em um servidor interno (ou no r-forge), para que meus colegas possam acessar o pacote. Porém, só publico no CRAN depois que o pacote é usado há meses ou até alguns anos por colegas próximos. Isso não traz todos os bugs de acordo com o ponto # 3 de Nick Cox, mas uma boa quantidade deles.
  As versões do pacote (eu coloquei a data após o traço no número da versão) facilitam a correção de coisas ("fazer isso e aquilo, certifique-se de instalar pelo menos a versão da semana passada")

• De acordo com meu contrato de trabalho, meu empregador tem a última palavra sobre a decisão sobre se e como um pacote pode ser publicado no mundo externo.

O que eu ainda não tenho uma boa estratégia para empacotar são os dados.

Comentários à sua lista de motivos:

• a inexistência de outros pacotes no mesmo subcampo;

Não encontrar um pacote que faça o que eu preciso aciona a gravação do código, mas isso não tem a ver com a decisão de empacotar ou não.

• a necessidade de intercambiar com outros pesquisadores e permitir a reprodutibilidade de experimentos;

Definitivamente. Possivelmente já existe a necessidade de compartilhar entre vários computadores que eu uso.

E entre os pontos que podem levar a uma decisão contrária:

• parte dos métodos usados ​​já presentes em alguns outros pacotes;

você pode importar esses métodos para o seu pacote / código: este é um argumento contra a gravação desse código, mas tem a ver indiretamente com o empacotamento.

• número de novas funções insuficientes para justificar a criação de um novo pacote independente.

Para mim, não há um número mínimo de funções para iniciar um pacote. Na minha experiência, os pacotes tendem a crescer "automaticamente". Pelo contrário, depois de me encontrar algumas vezes ramificando um novo pacote de outro (porque, por exemplo, algumas funções auxiliares no final se mostraram tematicamente diferentes e úteis em outras situações também), agora estou bastante criando novos pacotes imediatamente.

Além disso, se você não escreveu documentação e testes, isso pode ser uma quantidade proibitiva de trabalho quando um número "suficiente" de funções para criar um pacote se acumulou.
(Se você os escrever imediatamente, o esforço adicional de colocá-lo em um pacote será desprezível depois que você conhecer o fluxo de trabalho).

Eu diria que criar um pacote sempre que você estiver executando um conjunto suficientemente grande de tarefas semelhantes em R para se beneficiar de um pacote no qual poderá colocar coisas em um espaço para nome (para evitar conflitos com funções com nomes semelhantes), onde você pode escrever documentação. Eu até tenho um pacote no github para agrupar um pacote de funções que não estão relacionadas, mas uso com tanta frequência que achei que mereciam documentação, arquivos do homem etc.

Outro caso de uso poderia ser ao enviar um artigo, se você tiver várias funções, poderá criar facilmente um pacote, incluindo documentação para essas funções, exemplos para cada função e um tutorial sobre como usá-lo. E você não precisa colocá-lo no CRAN, como dito nas respostas acima. Isso pode ser incrível para a reprodutibilidade.

Eu diria que três ferramentas são importantes:

• devtools pkg , para tornar super fácil a compilação de pacotes (veja também o wiki nas páginas do devtools github
• roxygen2 pkg , para facilitar a documentação de escrita para seu pacote
• GitHub, você pode usar install_github(ou similarmente install_bitbucket, etc.) para instalar diretamente no GitHub, o que é bom para compartilhar com outras pessoas.

Eu concordo com tudo que li até agora. Todos esses motivos são boas práticas de programação e não se aplicam ao R em particular. No entanto, eu me pego escrevendo pacotes R na maioria das vezes, e por mais um motivo. Então vou adicionar:

Razão específica de R para escrever um pacote R:

• porque você escreve em C

Sempre que você usa idiomas estrangeiros como C, C ++ ou FORTRAN (principalmente para computação de alto desempenho), escrever um pacote vale muito a pena. Se você tiver mais de uma ou duas funções, acabará rapidamente com arquivos em todo o lugar e dependências entre os códigos R e C que são difíceis de manter e portar.

Um motivo não mencionado nas outras excelentes respostas: você tem um projeto de análise de dados grande ou complexo. Empacotando, primeiro, os dados como um pacote e depois estendendo-se com funções úteis para transformar, plotar ou calcular análises específicas. Dessa forma, você obtém uma versão documentada dos dados com todas as funções usadas para calcular a análise relatada. Em seguida, os relatórios do projeto podem ser escritos usando knitr ou outros pacotes para pesquisas reproduzíveis!

Isso pode economizar tempo significativamente, se for necessário fazer uma nova análise, ou até mesmo ser publicada (ou semi-publicada) se a análise for publicada.