[Bioc-devel] IRanges: 'extractROWS' fails for 'RangedData'
Hi, calling 'head' or 'tail' on a 'RangedData' objects fail with the lastest builds (R: 2013-09-14 r63932, IRanges: 1.19.35). The cause seems to be that there is no 'extractROWS' method that can be found for the signature 'RangedData'. As an example, see: ''' library(IRanges) ## generate the data ranges - IRanges(c(1,2,3),c(4,5,6)) rd = RangedData(ranges) ## this fails head(rd) ''' The last command returns: Error in (function (classes, fdef, mtable) : unable to find an inherited method for function ‘extractROWS’ for signature ‘RangedData’ Best wishes Julian ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] declaring package dependencies
I'm a little surprised by this thread. I subscribe to the RSS feeds of changes to NEWS (as Dirk mentioned) and that's been pretty informative in the past : http://developer.r-project.org/RSSfeeds.html Mainly though, I submit to winbuilder before submitting to CRAN, as the CRAN policies advise. winbuilder's R-devel seems to be built daily, saving me the time. Since I don't have Windows it kills two birds with one stone. It has caught many problems for me before submitting to CRAN and I can't remember it ever not responding in a reasonable time. http://win-builder.r-project.org/upload.aspx I've suggested before that winbuilder could be the mechanism to submit to CRAN rather than an ftp upload to incoming. Only if winbuilder passed OK on R-devel could it then go to a human. But iirc there was a technical difficulty preventing this. Matthew __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] declaring package dependencies
On 9/13/2013 12:15 PM, John Fox wrote: If I understand this thread, Michael's package doesn't use loglm() -- it provides methods for objects produced by loglm() and hence Enhances the package. Well, here's the rub: vcdExtra uses MASS::loglm() in examples, and also in R code, where it provides new S3 methods for loglm objects. And, this whole problem only arose after vcd (on which I Depend), modified its Imports to: Imports: utils, MASS, grDevices, colorspace where, previously, MASS had been a Depends (or Suggests?) there. For my examples, the old Suggests: MASS worked, but now I've used require(MASS) in each of those examples. However, the use in R code also triggered an error on loglm, even when I added Enhances: MASS to DESCRIPTION. OK, so I switched to using Imports: MASS but even that doesn't cure the problem alone. I then got: * checking dependencies in R code ... NOTE Namespace in Imports field not imported from: 'MASS' All declared Imports should be used. See the information on DESCRIPTION files in the chapter 'Creating R packages' of the 'Writing R Extensions' manual. but then an Error when an example using the function which called loglm() directly was run. ### ** Examples data(Titanic, package=datasets) # variables are in the order Class, Sex, Age, Survived tt - seq_loglm(Titanic) 1 model.string: = Class Error in eval(expr, envir, enclos) : could not find function loglm Calls: seq_loglm - eval - eval Execution halted So, as several people have suggested, I changed to use MASS::loglm() in code, though it still perplexes me why this is necessary. At any rate, this now passes R devel. Whew! Thanks to a suggestion from Mattew Dowle, I'm now using winbuilder (thx, Uwe for this!) and can get rather quick ( 30 min.) feedback on an R-devel build, whereas the R-Forge build cycle often takes a day. So, my workflow is now - R CMD check on local version in StatET - If OK, send to winbuilder, http://win-builder.r-project.org/upload.aspx - If OK, commit to R-Forge, and perhaps submit to CRAN if this is the final rev in a development cycle. But I still feel like I'm spending too much time on satisfying the unknown, new requirements of CRAN checks. As Dirk said (also deserving to be a fortune), Absent a time machine or psychic powers, I do not see how package developers can reasonably be expected to cope with this. The effort by R Core members that goes into R and CRAN is certainly herculean and I appreciate it very much. Like Dirk, I'm just looking for a little more predictability as CRAN evolves. -- Michael Friendly Email: friendly AT yorku DOT ca Professor, Psychology Dept. Chair, Quantitative Methods York University Voice: 416 736-2100 x66249 Fax: 416 736-5814 4700 Keele StreetWeb: http://www.datavis.ca Toronto, ONT M3J 1P3 CANADA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] declaring package dependencies
On 13-09-15 12:52 PM, Michael Friendly wrote: On 9/13/2013 12:15 PM, John Fox wrote: If I understand this thread, Michael's package doesn't use loglm() -- it provides methods for objects produced by loglm() and hence Enhances the package. Well, here's the rub: vcdExtra uses MASS::loglm() in examples, and also in R code, where it provides new S3 methods for loglm objects. And, this whole problem only arose after vcd (on which I Depend), modified its Imports to: Imports: utils, MASS, grDevices, colorspace where, previously, MASS had been a Depends (or Suggests?) there. For my examples, the old Suggests: MASS worked, but now I've used require(MASS) in each of those examples. However, the use in R code also triggered an error on loglm, even when I added Enhances: MASS to DESCRIPTION. OK, so I switched to using Imports: MASS but even that doesn't cure the problem alone. I then got: That just declares that MASS needs to be available, or installation of your package should abort. It doesn't actually import anything. You declare what parts of MASS you want to import in your NAMESPACE file. * checking dependencies in R code ... NOTE Namespace in Imports field not imported from: 'MASS' All declared Imports should be used. See the information on DESCRIPTION files in the chapter 'Creating R packages' of the 'Writing R Extensions' manual. but then an Error when an example using the function which called loglm() directly was run. If you had in your NAMESPACE file: importFrom(MASS, loglm) you wouldn't get the above error. ### ** Examples data(Titanic, package=datasets) # variables are in the order Class, Sex, Age, Survived tt - seq_loglm(Titanic) 1 model.string: = Class Error in eval(expr, envir, enclos) : could not find function loglm Calls: seq_loglm - eval - eval This looks like you're doing something tricky (those two evals), but normally if you are only calling loglm from your own internal code, you wouldn't need anything else. If you have an explicit call to loglm in your example, then it needs to be available to the user, so you could use the MASS::loglm notation, or (and this is probably a worse choice) you could export loglm from your package. Execution halted So, as several people have suggested, I changed to use MASS::loglm() in code, though it still perplexes me why this is necessary. At any rate, this now passes R devel. Whew! That will also work, though the importFrom solution is slightly cleaner and faster. The :: operator takes time to evaluate; with importFrom, it is effectively evaluated just once, when your package loads. (Of course, if MASS::loglm is only rarely used, you might not want to load it every time, and MASS::loglm might be the better choice.) Thanks to a suggestion from Mattew Dowle, I'm now using winbuilder (thx, Uwe for this!) and can get rather quick ( 30 min.) feedback on an R-devel build, whereas the R-Forge build cycle often takes a day. Yes, thanks Matthew for pointing this out, and Uwe for doing it. So, my workflow is now - R CMD check on local version in StatET - If OK, send to winbuilder, http://win-builder.r-project.org/upload.aspx - If OK, commit to R-Forge, and perhaps submit to CRAN if this is the final rev in a development cycle. But I still feel like I'm spending too much time on satisfying the unknown, new requirements of CRAN checks. As Dirk said (also deserving to be a fortune), Absent a time machine or psychic powers, I do not see how package developers can reasonably be expected to cope with this. These checks are not capricious, they are making your package better. For the present example, you were doing things in a way that just happened to work because of the way vcd was written. When it changed, your package broke. If you follow the new instructions, your package will be robust against changes like that. The effort by R Core members that goes into R and CRAN is certainly herculean and I appreciate it very much. Like Dirk, I'm just looking for a little more predictability as CRAN evolves. It is more the evolution of R that you are seeing, with CRAN serving as a giant testbed. As we identify predictable coding errors in packages, we add checks to R. If you have made those coding errors, then eventually you'll need to fix them. CRAN is just asking you to do it sooner, rather than later. However, I would guess that if you have an urgent fix in the package you are uploading, and something is going to stop you from fixing the newly identified problem, they'll be sympathetic to the need to allow your package to fix the urgent problem and keep the other one unfixed for a short time. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] declaring package dependencies
On 13-09-14 07:20 PM, Duncan Murdoch wrote: On 13-09-14 12:19 PM, Paul Gilbert wrote: On 13-09-14 09:04 AM, Duncan Murdoch wrote: On 13-09-13 12:00 PM, Dirk Eddelbuettel wrote: On 13 September 2013 at 11:42, Paul Gilbert wrote: | On 13-09-13 11:02 AM, Dirk Eddelbuettel wrote: | It's not so much Rcpp itself or my 20-ish packages but the fact that we (as | in the Rcpp authors) now stand behind an API that also has to accomodate | changes in R CMD check. Case in point is current (unannounced) change that | makes all Depends: Rcpp become Imports: Rcpp because of the NAMESPACE checks. | | I am a bit confused by this Dirk, so maybe I am missing something. I | think this is still a Note in R-devel so you do have some time to make | the change, at least several months, maybe more. It is not quite what I | think of as an announcement, more like a shot across the bow, but it | is also not unannounced. One package author [as in user of Rcpp and not an author of it] was told by CRAN this week to change his package and came to me for help -- so in that small way the CRAN non-communication policy is already creating more work for me, and makes me look silly as I don't document what Rcpp-using packages need as I sadly still lack the time machine or psychic powers to infer what may get changed this weekend. | More importantly, I don't think that the requirement is necessarily to | change Depends: Rcpp to Imports: Rcpp, the requirement is to put | imports(Rcpp) in the NAMESPACE file. I think this is so that the package | continues to work even if the user does something with the search path. | The decision to change Depends: Rcpp to Imports: Rcpp really depends on | whether the package author wants Rcpp functions to be available directly Rcpp is a bit of an odd-ball as you mostly need it at compile-time, and you require very few R-level functions (but there is package initialization etc pp). We also only about two handful of functions, and those are for functionality not all 135 packages use (eg Modules etc). But the focus here should not be on my hobby package. The focus needs to be on how four CRAN maintainers (who do a boatload of amazing work which is _truly_ appreciated in its thoroughness and reach) could make the life of authors of 4800+ packages easier by communicating and planning a tad more. Let me paraphrase that: The CRAN maintainers do a lot of work, and it helps me a lot, but if they only did a little bit more work it would help me even more. I suspect they'd be more receptive to suggestions that had them doing less work, not more. Actually, this is one of the parts that I do not understand. It seems to me that it would be a lot less work for CRAN maintainers if the implications and necessary changes to packages were explained a bit more clearly in a forum like R-devel that many package developers actually read regularly. Then why don't you explain them? They aren't secret. Well, I have been trying to do that on this and related threads over the past few weeks. But there is a large credibility difference between my explanation of something I am just learning about myself and an explanation by a core member or CRAN maintainer of something they have implemented. (At least, I hope most readers of this list know there is a difference.) I many not fully understand how much of the response to package submission gets done automatically, but I do get the sense that there is a fairly large amount of actual human time spent dealing with just my submissions alone. If that is representative of all developers, then CRAN maintainers don't have time to do much else. (The fact that they do much more suggests I may not be representative.) Two specific points have already been mentioned implicitly. CRAN submission testing is often done at a higher/newer level using the latest devel version. This results in lots of rejections for things that I would fix before submission, if I knew about them. Then why don't you test against R-devel before submitting? I have been relying on R-forge to provide that testing. One practical suggestion in this thread (Matthew Dowle) was to test with win-builder R-devel. This needs to be amplified. I had thought of win-builder as a mechanism to test on Windows, since I rarely work on that platform. Following the CRAN submission guidelines I test on win-builder if I am not doing the Windows testing on my own machine and the R-forge results are not available. (I think for a single package they are equivalent when R-forge is working.) But on win-builder I have usually used the R-release directory. Using the R-devel directory has the advantage that it gives an as-cran test that is almost up-to-date with the one against which the package is tested when it is submitted. Another feature of win-builder that I had not recognized is that submitted packages are available in its library for a short time, so packages with version dependencies can be
[Rd] R-Forge SVN commit hook to email appears to be broken
It would appear that commits no longer trigger emails; for Rcpp at least we are two commits (made earlier today) ahead of what was emailed. Maybe the mail agent needs to be restarted? Many thanks for taking care of r-forge. It is appreciated. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] declaring package dependencies
Something that might be of use to you guys is crant (https://github.com/muxspace/crant), which is a set of scripts to make package development and testing simpler. With crant you can build out multiple R instances (release, patch, devel) and then run the build chain against each one. It's compatible with devtools, and we're working on a few other conveniences, like testing all the the reverse depends to understand whether a change to a package breaks downstream dependencies. I've certainly bitten myself and incurred the wrath of CRAN a few times because I didn't check this sort of thing thoroughly enough. Running this on a virtual machine ensures that the environment is clean for building/testing. Of course, it doesn't address the communication issues (which I find somewhat amusing because the CRAN maintainers always seem to be in absentia during these discussions), but assuming that the CRAN checks are added to the devel branch, it shouldn't matter insomuch as detecting them prior to submission. Understanding the rationale for the change is a different matter. Brian On Sep 15, 2013, at 2:05 PM, Paul Gilbert pgilbert...@gmail.com wrote: On 13-09-14 07:20 PM, Duncan Murdoch wrote: On 13-09-14 12:19 PM, Paul Gilbert wrote: I many not fully understand how much of the response to package submission gets done automatically, but I do get the sense that there is a fairly large amount of actual human time spent dealing with just my submissions alone. If that is representative of all developers, then CRAN maintainers don't have time to do much else. (The fact that they do much more suggests I may not be representative.) Two specific points have already been mentioned implicitly. CRAN submission testing is often done at a higher/newer level using the latest devel version. This results in lots of rejections for things that I would fix before submission, if I knew about them. Then why don't you test against R-devel before submitting? I have been relying on R-forge to provide that testing. One practical suggestion in this thread (Matthew Dowle) was to test with win-builder R-devel. This needs to be amplified. I had thought of win-builder as a mechanism to test on Windows, since I rarely work on that platform. Following the CRAN submission guidelines I test on win-builder if I am not doing the Windows testing on my own machine and the R-forge results are not available. (I think for a single package they are equivalent when R-forge is working.) But on win-builder I have usually used the R-release directory. Using the R-devel directory has the advantage that it gives an as-cran test that is almost up-to-date with the one against which the package is tested when it is submitted. Another feature of win-builder that I had not recognized is that submitted packages are available in its library for a short time, so packages with version dependencies can be tested there, whereas they cannot be tested on R-forge. If the tests were rolled out with R, and only later incorporated into CRAN submission testing, I think there would be a lot less work for the CRAN maintainers. I am an R core member, not a member of CRAN. If I make a change to R, I'd like to know the effect it has on the corpus of CRAN and Bioconductor packages, but I don't have the computing resources to run it against all of those in a reasonable amount of time. We have heard from various corporate users of R (Revolution Computing and Google are two) that they would like to contribute to the project, but we don't actually see useful contributions from them. I don't know if you personally have influence with anyone who has such resources, As far as I know I don't have any influence with anybody, but I like this suggestion. Paul but surely some on this list do. So why don't they write to me and tell me how to use their computing resources to run proposed changes against all published packages? I think it's because it's easier to do nothing than to do something. It's certainly easier to say that it's the CRAN maintainers' fault for poor communication than it is to identify and address the problems. Duncan Murdoch (This is ignoring the possibility that CRAN submission is really the testing ground for the tests, and to prove the tests requires a fair amount of manual involvement. I'm happy to continue contributing to this -- I've often felt my many contribution is an endless supply of bugs for the checkers to catch.) The second point is that a facility like R-forge that runs the latest checks, on many platforms, is really useful in order to reduce work for both package developers and CRAN maintainers. With R-forge broken, the implication for additional work for CRAN maintainers seems enormous. But even with it working, not all packages are kept on R-forge, and with package version dependencies R-forge does not really work. (i.e. I have to get
[Rd] FOSS licence with BuildVignettes: false
Dear All, I have been checking the metafor package against R-devel. R CMD check --as-cran metafor yields one note: FOSS licence with BuildVignettes: false Yes, I have 'BuildVignettes: FALSE' in my DESCRIPTION file. I see at http://developer.r-project.org/blosxom.cgi/R-devel/NEWS: Tue, 25 Jun 2013 CHANGES IN R-devel UTILITIES 'R CMD check --as-cran' warns about a false value of the 'DESCRIPTION' field 'BuildVignettes' for Open Source packages, and ignores it (as an Open Source package needs to have complete sources for its vignettes). My questions are: 1) Is this going to be an issue if I submit a new version of the metafor package to CRAN right now? 2) And if the answer to 1 is Not right now: Is this going to become an issue in the future? In other words, is it the goal to only allow packages with BuildVignettes=true if they have an FOSS license at some point in the future? Best, Wolfgang -- Wolfgang Viechtbauer, Ph.D., Statistician Department of Psychiatry and Psychology School for Mental Health and Neuroscience Faculty of Health, Medicine, and Life Sciences Maastricht University, P.O. Box 616 (VIJV1) 6200 MD Maastricht, The Netherlands +31 (43) 388-4170 | http://www.wvbauer.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] FOSS licence with BuildVignettes: false
Setting BuildVignettes: false is fine if it is possible to build the vignettes, and the latter is checked in CRAN incoming checks (but not the daily checks). Uwe Ligges On 15.09.2013 22:13, Viechtbauer Wolfgang (STAT) wrote: Dear All, I have been checking the metafor package against R-devel. R CMD check --as-cran metafor yields one note: FOSS licence with BuildVignettes: false Yes, I have 'BuildVignettes: FALSE' in my DESCRIPTION file. I see at http://developer.r-project.org/blosxom.cgi/R-devel/NEWS: Tue, 25 Jun 2013 CHANGES IN R-devel UTILITIES 'R CMD check --as-cran' warns about a false value of the 'DESCRIPTION' field 'BuildVignettes' for Open Source packages, and ignores it (as an Open Source package needs to have complete sources for its vignettes). My questions are: 1) Is this going to be an issue if I submit a new version of the metafor package to CRAN right now? 2) And if the answer to 1 is Not right now: Is this going to become an issue in the future? In other words, is it the goal to only allow packages with BuildVignettes=true if they have an FOSS license at some point in the future? Best, Wolfgang -- Wolfgang Viechtbauer, Ph.D., Statistician Department of Psychiatry and Psychology School for Mental Health and Neuroscience Faculty of Health, Medicine, and Life Sciences Maastricht University, P.O. Box 616 (VIJV1) 6200 MD Maastricht, The Netherlands +31 (43) 388-4170 | http://www.wvbauer.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] FOSS licence with BuildVignettes: false
Uwe Ligges ligges at statistik.tu-dortmund.de writes: Setting BuildVignettes: false is fine if it is possible to build the vignettes, and the latter is checked in CRAN incoming checks (but not the daily checks). Uwe Ligges Hmmm. I was told by the CRAN maintainers on Aug 7 that CRAN FOSS licence with BuildVignettes: false is not a false positive, CRAN is fixable, and is mentioned at CRAN http://cran.r-project.org/doc/manuals/r-devel/R-exts.html# CRANThe-DESCRIPTION-file as not to be used in an FOSS package. (I had said in my previous e-mail to CRAN that all NOTEs were false positives, minor or not fixable.) Admittedly this e-mail nowhere said explicitly you must fix this or we will not accept it for CRAN, but that was certainly the impression I got. TFM says R-exts [BuildVignettes: false] should only be used exceptionally, for R-exts example if the PDFs include large figures which are not part of the R-exts package sources (and hence only in packages which do not have an R-exts Open Source license). So either I'm confused (always a possibility!) or it seems there are some inconsistencies here ... On 15.09.2013 22:13, Viechtbauer Wolfgang (STAT) wrote: Dear All, I have been checking the metafor package against R-devel. R CMD check --as-cran metafor yields one note: FOSS licence with BuildVignettes: false Yes, I have 'BuildVignettes: FALSE' in my DESCRIPTION file. I see at http://developer.r-project.org/blosxom.cgi/R-devel/NEWS: Tue, 25 Jun 2013 CHANGES IN R-devel UTILITIES 'R CMD check --as-cran' warns about a false value of the 'DESCRIPTION' field 'BuildVignettes' for Open Source packages, and ignores it (as an Open Source package needs to have complete sources for its vignettes). My questions are: 1) Is this going to be an issue if I submit a new version of the metafor package to CRAN right now? 2) And if the answer to 1 is Not right now: Is this going to become an issue in the future? In other words, is it the goal to only allow packages with BuildVignettes=true if they have an FOSS license at some point in the future? Best, Wolfgang __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] declaring package dependencies
Matthew Dowle mdowle at mdowle.plus.com writes: I'm a little surprised by this thread. I subscribe to the RSS feeds of changes to NEWS (as Dirk mentioned) and that's been pretty informative in the past : http://developer.r-project.org/RSSfeeds.html Mainly though, I submit to winbuilder before submitting to CRAN, as the CRAN policies advise. winbuilder's R-devel seems to be built daily, saving me the time. Since I don't have Windows it kills two birds with one stone. It has caught many problems for me before submitting to CRAN and I can't remember it ever not responding in a reasonable time. http://win-builder.r-project.org/upload.aspx I've suggested before that winbuilder could be the mechanism to submit to CRAN rather than an ftp upload to incoming. Only if winbuilder passed OK on R-devel could it then go to a human. But iirc there was a technical difficulty preventing this. Matthew I was planning to write a careful e-mail to CRAN suggesting essentially this, and I may yet do so, but for now I'll just chime in and +1 this. Yihui Xie made a very similar suggestion sometime last year (I think). It would seem so much easier for everyone, package maintainers *and* CRAN maintainers, to have an automatic filter of this sort, and I can't figure out any downside other than needing slightly more computer power (which surely must be a reasonable tradeoff for fewer human resources!), *if* having the auto-filter made people sloppier about checking before submitting. Do you happen to remember what the technical difficulty was? If I were a CRAN maintainer (thank goodness I'm not!), overcoming it would be one of my top priorities ... Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] declaring package dependencies
I've been watching this thread closely and trying not to chime in, because as Brian Rowe mentioned about CRAN's mysterious absence in a previous reply. CRAN is like a ghost in r-devel (or any other mailing lists) -- everybody is discussing about it, and nobody has ever seen it. Perhaps one day useRs will realize that the rings of Saturn are actually composed of the lost discussions about CRAN. (Just kidding. No offence. I swear I appreciate the great work of CRAN, and rep(thank you, CRAN, 1e6).) Although this discussion may also contribute to the rings of Saturn, I want to emphasize one final point: requests from package authors do not necessarily mean more work for CRAN. Regards, Yihui -- Yihui Xie xieyi...@gmail.com Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Sun, Sep 15, 2013 at 6:11 PM, Ben Bolker bbol...@gmail.com wrote: Matthew Dowle mdowle at mdowle.plus.com writes: I'm a little surprised by this thread. I subscribe to the RSS feeds of changes to NEWS (as Dirk mentioned) and that's been pretty informative in the past : http://developer.r-project.org/RSSfeeds.html Mainly though, I submit to winbuilder before submitting to CRAN, as the CRAN policies advise. winbuilder's R-devel seems to be built daily, saving me the time. Since I don't have Windows it kills two birds with one stone. It has caught many problems for me before submitting to CRAN and I can't remember it ever not responding in a reasonable time. http://win-builder.r-project.org/upload.aspx I've suggested before that winbuilder could be the mechanism to submit to CRAN rather than an ftp upload to incoming. Only if winbuilder passed OK on R-devel could it then go to a human. But iirc there was a technical difficulty preventing this. Matthew I was planning to write a careful e-mail to CRAN suggesting essentially this, and I may yet do so, but for now I'll just chime in and +1 this. Yihui Xie made a very similar suggestion sometime last year (I think). It would seem so much easier for everyone, package maintainers *and* CRAN maintainers, to have an automatic filter of this sort, and I can't figure out any downside other than needing slightly more computer power (which surely must be a reasonable tradeoff for fewer human resources!), *if* having the auto-filter made people sloppier about checking before submitting. Do you happen to remember what the technical difficulty was? If I were a CRAN maintainer (thank goodness I'm not!), overcoming it would be one of my top priorities ... Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] declaring package dependencies
That reminds me: I once made a suggestion on how to automate some of the CRAN deployment process, but it was shot down as not being useful to them. I do recall a quote that was along the lines of as long as you don't need help, do whatever you want, so one thought is to just set up a build server that does the building across the three versions of R, checks dependencies, rebuilds when release, patch, or devel are updated, etc. This would ease the burden on package maintainers and would just happen to make the CRAN folks' lives easier by catching a lot of bad builds. A proof of concept on AWS connecting to github or rforge could probably be finished on a six-pack. Speak up if anyone thinks this would be useful. On Sep 15, 2013, at 9:58 PM, Yihui Xie x...@yihui.name wrote: I've been watching this thread closely and trying not to chime in, because as Brian Rowe mentioned about CRAN's mysterious absence in a previous reply. CRAN is like a ghost in r-devel (or any other mailing lists) -- everybody is discussing about it, and nobody has ever seen it. Perhaps one day useRs will realize that the rings of Saturn are actually composed of the lost discussions about CRAN. (Just kidding. No offence. I swear I appreciate the great work of CRAN, and rep(thank you, CRAN, 1e6).) Although this discussion may also contribute to the rings of Saturn, I want to emphasize one final point: requests from package authors do not necessarily mean more work for CRAN. Regards, Yihui -- Yihui Xie xieyi...@gmail.com Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Sun, Sep 15, 2013 at 6:11 PM, Ben Bolker bbol...@gmail.com wrote: Matthew Dowle mdowle at mdowle.plus.com writes: I'm a little surprised by this thread. I subscribe to the RSS feeds of changes to NEWS (as Dirk mentioned) and that's been pretty informative in the past : http://developer.r-project.org/RSSfeeds.html Mainly though, I submit to winbuilder before submitting to CRAN, as the CRAN policies advise. winbuilder's R-devel seems to be built daily, saving me the time. Since I don't have Windows it kills two birds with one stone. It has caught many problems for me before submitting to CRAN and I can't remember it ever not responding in a reasonable time. http://win-builder.r-project.org/upload.aspx I've suggested before that winbuilder could be the mechanism to submit to CRAN rather than an ftp upload to incoming. Only if winbuilder passed OK on R-devel could it then go to a human. But iirc there was a technical difficulty preventing this. Matthew I was planning to write a careful e-mail to CRAN suggesting essentially this, and I may yet do so, but for now I'll just chime in and +1 this. Yihui Xie made a very similar suggestion sometime last year (I think). It would seem so much easier for everyone, package maintainers *and* CRAN maintainers, to have an automatic filter of this sort, and I can't figure out any downside other than needing slightly more computer power (which surely must be a reasonable tradeoff for fewer human resources!), *if* having the auto-filter made people sloppier about checking before submitting. Do you happen to remember what the technical difficulty was? If I were a CRAN maintainer (thank goodness I'm not!), overcoming it would be one of my top priorities ... Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
