Provide ability to check `noSuggest`

[JosiahParry]

Is your feature request related to a problem? Please describe.

I have had a package removed from CRAN 2 times over the course of 2 months for failing to address noSuggests. The noSuggest requirement is that any examples cannot use suggested packages. This is true for recursive Imports as well. I have fixed these issues, submitted, and had the changes accepted. Only to immediately be smacked on the wrist with the same issue but somewhere else.

CRAN does not provide a way to check these issues.

Describe the solution you'd like

I would like for there to be an argument in devtools::check() that allows a user to check the noSuggests requirement.

Describe alternatives you've considered

I previously had examples surrounded in \donttest{} and \dontrun{} but CRAN no longer respectss those flags for examples. They are tested anyways.

Additional context Add any other context or about the feature request here.

[jennybc]

Based on what I see here:

https://cran.r-project.org/web/checks/check_issue_kinds.html

CRAN Package Check Issue Kinds == noSuggests means this:

Ttests on x86_64 Linux with R-devel using _R_CHECK_DEPENDS_ONLY_=true,
so packages in Suggests (and Enhances) are not available (other
than recommended packages).

For this to work as intended, add-on packages need to be installed
in a library other than .Library.

Other details as 
https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-devel-linux-x86_64-fedora-gcc

Packages get reported here when they have used a suggested/enhances 
package which is unavailable.  Since such packages come and go, they
will continue to be checked and reported here if they fail again.

So the key environment variable setting seems to be _R_CHECK_DEPENDS_ONLY_=true. I would try setting this in the env_var argument of check().

[jennybc]

AFAIK this is not a standard setting for incoming or even regular ongoing package checks. So I wonder if the package(s) in question were flagged for other reasons, then received a more stringent level of checking (which I have experienced).

[JosiahParry]

That's likely the case. It was initially flagged in November I think because a suggested package (readr if I recall) was temporarily unavailable.

Setting the env_vars argument technically worked but since all of the suggested packages are installed at .Library there were no issues. One way I could consider handling this is using renv to build a temporary package location. But it seems like the only "effective" way to do this would be using some CI :/

[jennybc]

because a suggested package (readr if I recall) was temporarily unavailable

I maintain readr and I'm not aware of any interruption in its availability on CRAN.

Setting the env_vars argument technically worked but since all of the suggested packages are installed at .Library there were no issues.

I think that suggests an improvement you could make in your dev environment, i.e. your main dev machine. I think it's a good practice to never allow anything other than base and recommended packages in .Library. Instead, I recommend using a user library for all add-on packages. I think if you switched to this setup at the next convenient time, i.e. when doing a clean install or upgrading R, it would have a generally positive effect on your development life. And, in this specific case, would make it easier to run this specialized check.

The best instructions I have lying around for this are here:

https://rstats.wtf/maintaining-r.html#how-to-transfer-your-library-when-updating-r

This is the key step to do after installing R, but before starting to install any add-on packages:

fs::dir_create(Sys.getenv("R_LIBS_USER"))

Also, as I recall, this basically happens by default on Windows (having a user library), but folks on macOS need to explicitly create this directory.