Re: [Rd] Petition to set warnPartialMatch* options to TRUE
> Therneau, Terry M , Ph D writes: > Let me give partial assent to Michael's suggestion: a) have an easy way to > turn this on and b) add a strong suggestion to do so to the WRE manual. > Kurt's example in the email shows how to do (a); but I just looked in the > WRE manual and don't see any reference to it, nor any mention from R CMD > check --help, so I don't know where I would have found out about it. > I have gotton warnings about partial matches from CRAN wrt the survival > package --- I suspect at the benefit of Kurt --- and though I muttered under > my breath about it at the time there is no doubt that it was a good idea to > fix all of them, and I'm glad for the nudge. > Kurt: does that envionment variable contain the options string itself, or > does it point to a file containing the options? The latter: one can use _R_CHECK_EXAMPLES_PROFILE_ to point to a profile containing e.g. options(warnPartialMatchArgs = TRUE, warnPartialMatchAttr = TRUE, warnPartialMatchDollar = TRUE, showErrorCalls = TRUE, showWarnCalls = TRUE) Best -k > I appreciate partial matching when typing code at the terminal so want the > feature to remain in that context. > Terry T > -- > Terry M Therneau, PhD > Department of Quantitative Health Sciences > Mayo Clinic > thern...@mayo.edu > "TERR-ree THUR-noh" __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Petition to set warnPartialMatch* options to TRUE
Let me give partial assent to Michael's suggestion: a) have an easy way to turn this on and b) add a strong suggestion to do so to the WRE manual. Kurt's example in the email shows how to do (a); but I just looked in the WRE manual and don't see any reference to it, nor any mention from R CMD check --help, so I don't know where I would have found out about it. I have gotton warnings about partial matches from CRAN wrt the survival package --- I suspect at the benefit of Kurt --- and though I muttered under my breath about it at the time there is no doubt that it was a good idea to fix all of them, and I'm glad for the nudge. Kurt: does that envionment variable contain the options string itself, or does it point to a file containing the options? I appreciate partial matching when typing code at the terminal so want the feature to remain in that context. Terry T -- Terry M Therneau, PhD Department of Quantitative Health Sciences Mayo Clinic thern...@mayo.edu "TERR-ree THUR-noh" [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Petition to set warnPartialMatch* options to TRUE during R CMD check by default
> Michael Chirico writes:
Michael,
You may have seen that some time ago I added
check.R:cprof <- Sys.getenv("_R_CHECK_EXAMPLES_PROFILE_", "")
etc so one can use the _R_CHECK_EXAMPLES_PROFILE_ env var to specify a
profile to use when running the examples, e.g.
options(warnPartialMatchArgs = TRUE,
warnPartialMatchAttr = TRUE,
warnPartialMatchDollar = TRUE)
In principle one could do this by default, because it has no effect:
such warnings in the output will not be seen in the check log by
default. One could change that, but then the problem is that there is
no way to filter the warnings according to where they come from.
I had used the mechanism to eliminate partial matches from the base R
packages. I had also tried using it for my own CRAN packages, and fixed
the ones under my control, and reported the others, most of which never
got fixed ...
Best
-k
> Hi all,
> What it says in the title. This is likely to cause a lot of CRAN packages
> to fail (I can try and quantify this if seen fit), but I think it's for the
> best. Packages should not (IMHO) be relying on partial matching in package
> code / tests. One might be more permissive for vignette/examples code,
> though I still find it poor practice.
> Among many reasons why package authors should resist using partial
> matching, today I saw this:
> upstream package A adds a new argument 'nb' to its print method, now there
> are two arguments 'na' and 'nb' starting with 'n'
> downstream package B importing A starts failing because it was using
> print(n=...) and relying on that resolving to na= but now it's ambiguous
> This feels like an unnecessary risk for considerate package A authors to
> need to take into account when designing their API. Yes, downstream package
> B "should" be broken & resubmitted to CRAN, but (1) there is some perceived
> "blame" for package A "causing B to be removed" and (2) the re-submitted
> package is by no means assured to be "safe" -- time-constrained B authors
> may just fix the minimum set of partially-matched calls while leaving
> potentially many other similar at-risk call sites unchanged.
> Better to enforce exact matching in package code globally, I think.
> It seems likely (given how options work in R) that committed authors will
> be able to sidestep the issue by disabling the PartialMatch warnings, but
> better to make this inconvenient with a stricter default.
> Mike C
> [[alternative HTML version deleted]]
> __
> 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
