[Rd] Petition to set warnPartialMatch* options to TRUE during R CMD check by default

Michael Chirico m|ch@e|ch|r|co4 @end|ng |rom gm@||@com
Mon Apr 22 20:16:51 CEST 2024


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



More information about the R-devel mailing list