>>>>> Michael Lawrence <lawrence.mich...@gene.com> >>>>> on Sat, 4 Mar 2017 12:20:45 -0800 writes:
> Is there really a need for these complications? Packages > emitting this warning are broken by definition and should be fixed. I agree and probably Henrik, too. (Others may disagree to some extent .. and find it convenient that R does translate 'if(x)' to 'if(x[1])' for them albeit with a warning .. ) > Perhaps we could "flip the switch" in a test > environment and see how much havoc is wreaked and whether > authors are sufficiently responsive? > Michael As we have > 10'000 packages on CRAN alonce, and people have started (mis)using suppressWarnings(.) in many places, there may be considerably more packages affected than we optimistically assume... As R core member who would "flip the switch" I'd typically then have to be the one sending an e-mail to all package maintainers affected.... and in this case I'm very reluctant to volunteer for that and so, I'd prefer the environment variable where R core and others can decide how to use it .. for a while .. until the flip is switched for all. or have I overlooked an issue? Martin > On Sat, Mar 4, 2017 at 12:04 PM, Martin Maechler > <maech...@stat.math.ethz.ch >> wrote: >> >>>>> Henrik Bengtsson <henrik.bengts...@gmail.com> >>>>> >> on Fri, 3 Mar 2017 10:10:53 -0800 writes: >> >> > On Fri, Mar 3, 2017 at 9:55 AM, Hadley Wickham > >> <h.wick...@gmail.com> wrote: >>> But, how you propose a >> warning-to-error transition >>> should be made without >> wreaking havoc? Just flip the >>> switch in R-devel and >> see CRAN and Bioconductor packages >>> break overnight? >> Particularly Bioconductor devel might >>> become >> non-functional (since at times it requires >>> R-devel). >> For my own code / packages, I would be able >>> to handle >> such a change, but I'm completely out of >>> control if >> one of the package I'm depending on does not >>> provide >> a quick fix (with the only option to remove >>> package >> tests for those dependencies). >> >> >> >> Generally, a package can not be on CRAN if it has any >> >> warnings, so I don't think this change would have any >> >> impact on CRAN packages. Isn't this also true for >> >> bioconductor? >> >> > Having a tests/warn.R file with: >> >> > warning("boom") >> >> > passes through R CMD check --as-cran unnoticed. >> >> Yes, indeed.. you are right Henrik that many/most R >> warning()s would not produce R CMD check 'WARNING's .. >> >> I think Hadley and I fell into the same mental pit of >> concluding that such warning()s from >> if(<length-larger-one>) ... would not currently happen >> in CRAN / Bioc packages and hence turning them to errors >> would not have a direct effect. >> >> With your 2nd e-mail of saying that you'd propose such an >> option only for a few releases of R you've indeed >> clarified your intent to me. OTOH, I would prefer using >> an environment variable (as you've proposed as an >> alternative) which is turned "active" at the beginning >> only manually or for the "CRAN incoming" checks of the >> CRAN team (and bioconductor submission checks?) and >> later for '--as-cran' etc until it eventually becomes the >> unconditional behavior of R (and the env.variable is no >> longer used). >> >> Martin >> >> ______________________________________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel