From Achim.Zeileis at uibk.ac.at  Thu Jan 22 18:45:22 2015
From: Achim.Zeileis at uibk.ac.at (Achim Zeileis)
Date: Thu, 22 Jan 2015 18:45:22 +0100 (CET)
Subject: [Rd] Programming Tools CTV
In-Reply-To: <CAJ9CoWmTp_0UmL6UQ+iGBjbm-QXWxEyVsYWjhTWBj3YOXv3kKA@mail.gmail.com>
References: <CAJ9CoWmTp_0UmL6UQ+iGBjbm-QXWxEyVsYWjhTWBj3YOXv3kKA@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1501221838260.22244@paninaro.uibk.ac.at>

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?

Best,
Z

> Thanks,
>
> Max
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



[Rd] Programming Tools CTV
Achim Zeileis