[Rd] Programming Tools CTV

[Achim Zeileis]

On Thu, 22 Jan 2015, Max Kuhn wrote:

> On Thu, Jan 22, 2015 at 12:45 PM, Achim Zeileis
> <Achim.Zeileis at uibk.ac.at> wrote:
>> On Thu, 22 Jan 2015, Max Kuhn wrote:
>>
>>> I've had a lot of requests for additions to the reproducible research
>>> task view that fall into a grey area (to me at least).
>>>
>>> For example, roxygen2 is a tool that broadly enable reproducibility
>>> but I see it more as a tool for better programming. I'm about to check
>>> in a new version of the task view that includes packrat and
>>> checkpoint, as they seem closer to reproducible research, but also
>>> feel like coding tools.
>>>
>>> There are a few other packages that many would find useful for better
>>> coding: devtools, testthat, lintr, codetools, svTools, rbenchmark,
>>> pkgutils, etc.
>>>
>>> This might be some overlap with the HPC task view. I would think that
>>> rJava, Rcpp and the like are better suited there but this is arguable.
>>>
>>> The last time I proposed something like this, Martin deftly convinced
>>> me to be the maintainer. It is probably better for everyone if we
>>> avoid that on this occasion.
>>>
>>> * Does anyone else see the need for this?
>>>
>>> * What other packages fit into this bin?
>>>
>>> * Would anyone like to volunteer?
>>
>>
>> Max, thanks for the suggestion. We had a somewhat related proposal on R-help
>> from Luca Braglia a couple of months ago, suggesting a "Package Development"
>> task view:
>> https://mailman.stat.ethz.ch/pipermail/r-devel/2014-July/069454.html
>>
>> He put up some ideas on Github:
>> https://github.com/lbraglia/PackageDevelopmentTaskView
>>
>> When Luca asked me (ctv maintainer) and Dirk (HPC task view maintainer) for
>> feedback off-list, I replied that it is important that task views are
>> focused in order to be useful and maintainable. My feeling was that
>> "PackageDevelopment" was too broad and also "ProgrammingTools" is still too
>> board, I think. This could mean a lot of things/tools to a lot of people.
>>
>> But maybe it would be to factor out some aspect that is sharp and clear(er)?
>> Or split it up into bits where there are (more or less) objectively clear
>> criteria for what goes in and what does not?
>
> It's funny that you said that. As I was updating the RR CTV, it
> realized what a beast it is right now. I thought about making a github
> project earlier today that would have more detailed examples and
> information.
>
> I see two problems with that as the *sole* solution.
>
> First, it is divorced from CRAN CTV and that is a place that people
> know and will look. I had no idea of Luca's work for this exact
> reason.
>
> Secondly, might be intimidating for new R users who, I think, are the
> targeted cohort for the CTVs.

Yes, I agree. There should (an) additional task view(s) on CRAN related to 
this.

> How about a relatively broad definition that is succinct in content
> with a link to a github repos?

I think this doesn't fit well with the existing development model and 
might require duplicating changes in the <packagelist> of the task view. 
In order to be easily installable I need the <packagelist> in the task 
view on CRAN and not just in the linked list on Github.

Therefore, I would suggest splitting up the topic into things that are 
fairly sharp and clear. (Of course, it is impossible to avoid overlap 
completely.) For example, one could add "LanguageInterfaces" or something 
like that.

And the task views on CRAN can always include <links> to further 
documentation on Github and elsewhere. Especially when it comes to package 
development there are also clearly different preferences about what is 
good style or the right tools (say Github vs. R-Forge, knitr vs. Sweave, 
etc.)

> Thanks,
>
> Max
>