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