On Thu, Jan 22, 2015 at 1:05 PM, Achim Zeileis <achim.zeil...@uibk.ac.at> wrote: > On Thu, 22 Jan 2015, Max Kuhn wrote: > >> On Thu, Jan 22, 2015 at 12:45 PM, Achim Zeileis >> <achim.zeil...@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.
Many of the task views are encyclopedic and still focused. Perhaps my issues with RR are more related to how I currently organize it. I'll try to solve it that way. > 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. Looking at Luca's page, I think he does a great job of clustering packages. My suggestions for focused topics are: - Package Development* - Foreign Languages Interfaces - Code Analysis and Debugging - Profiling and Benchmarking - Unit Testing * I would define the first one to be more narrow than the original definition. I think that most of these would encompass less than 10 packages if we don't include all the Rcpp depends =] > 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.) Yes. The comments above would not exclude this approach, which is/was/might be my intention for RR. Thanks, Max ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
