min_r_version_linter() to detect invalid or missing minimum R version in R package

[IndrajeetPatil]

The problem is explained quite well through this example: rvlenth/emmeans#489

With the precedent of the cyclocomp linter, we can now introduce linters that use a suggested dependency, and I think this would come in handy here. In particular, I think the dependency solver in {pkgdepends} can be quite helpful to figure out the correct minimum needed R version.

Of course, this is going to detect the minimum required R version only by looking at the dependency graph. Figuring that out by checking if any newer R functions are used would be a more challenging task, and I don't consider that to be in the scope of this issue.

WDYT?

[MichaelChirico]

Funny, I just filed r-lib/rcmdcheck#220 yesterday.

I'm not seeing how this works as an R linter though, isn't this a DESCRIPTION linter? But then it's out of scope: #889

[IndrajeetPatil]

then it's out of scope

Can we please relitigate this?

We do support a class of linters that are designed for package development and, given that it's the DESCRIPTION file that turns a folder into package, I think linting its contents could also fall under the purview of lintr.

[AshesITR]

This really seems like more trouble than it's worth to me.
Here are some thoughts on the matter:

If we were to support linting DESCRIPTION files, this would need to be supported in lint() so we need to make a smart (= complex?) way to determine how to proceed with linting the requested file. Alternatively, we could provide completely separate entry points, like lint_description().
Then, how to we handle config management for these linters? And how do we do name description linters to separate them from R code linters?
Or, if we don't, how do we setup linter metadata to deal with different languages, likely requiring completely separate parsing logic?

[IndrajeetPatil]

Hmm, yeah, I see what you mean.

We probably need to outsource this either to another package (e.g. {goodpractice}), or, if we have enough issues, we could consider creating a new extension package of {lintr} that deals only with lints related to the DESCRIPTION file (and other package-related metadata).

[IndrajeetPatil]

Should I create an issue to scope out {lintr.meta}, which we can keep updating as we think of new features?

This would actually be a good candidate for GitHub Discussions.
@MichaelChirico Do you have the necessary privileges for this repo to turn on Discussions? Just an idea; I am also fine with using issue for this.