R devel - Apr 2024 - Petition to set warnPartialMatch* options to TRUE during R CMD check by default

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

>>>>> 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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel