[Rd] Programming Tools CTV

[Achim Zeileis]

On Thu, 22 Jan 2015, Max Kuhn wrote:

> On Thu, Jan 22, 2015 at 1:05 PM, Achim Zeileis <Achim.Zeileis at uibk.ac.at> wrote:
>> 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.
>
> 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

Yes, good suggestions. Now we only need willing maintainers :-)

> * I would define the first one to be more narrow than the original 
> definition.

It's probably still the fuzziest one in the list above.

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

True.

thx,
Z