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? Thanks, Max
Programming Tools CTV
9 messages · Gregory R. Warnes, Henrik Bengtsson, Luca Braglia +2 more
I second the motion for a Programming Tools CRAN Task View. I would also think it could contain things like Rcpp, R6, etc. -Greg
On Jan 22, 2015, at 10:20 AM, Max Kuhn <mxkuhn at gmail.com> 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? Thanks, Max
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
On Thu, Jan 22, 2015 at 7:20 AM, Max Kuhn <mxkuhn at gmail.com> 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?
Thanks for your work on this. May I suggest a Git/GitHub repository for this? That lowers the barriers for contributions substantially, e.g. either via issues but even better via pull requests (== point'n'click for you). If you need to mirror/push it to an SVN repository, I'm sure that's pretty easy to do (and likely also to automate). /Henrik PS. Sorry, I'm not volunteering; too much on my plate.
Thanks, Max
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Hi, this summer, after few mails on this list, i started something similar (feeling the same need)... here is the repo https://github.com/lbraglia/PackageDevelopmentTaskView Currently it's quite freezed since i'm working on other projects in my free software spare time (and likely i won't return to it) but could be a starting point for someone else interested. Best, Luca PS in the case, following some mails with Dirk and Achim, HPC stuff a-la Rcpp and friends should not be copied from Dirk's stuff, better pointing... it was in my mental TODO 2015-01-22 18:23 GMT+01:00 Gregory R. Warnes <greg at warnes.net>:
I second the motion for a Programming Tools CRAN Task View. I would also think it could contain things like Rcpp, R6, etc. -Greg
On Jan 22, 2015, at 10:20 AM, Max Kuhn <mxkuhn at gmail.com> 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? Thanks, Max
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
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
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. How about a relatively broad definition that is succinct in content with a link to a github repos? Thanks, Max
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
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 * 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
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