Add support for suggests field in standalone files

[eitsupi]

As like #1789, I wonder suggests field should be allowed in standalone files.

For example, https://github.com/r-lib/rlang/blob/3d48c13d052724cd5997a730ea41bc8e6991691b/R/standalone-cli.R includes cli::, so the cli package is needed in the Suggests filed of the DESCRIPTION file.

[jennybc]

Well, the reason you see cli:: in standalone-cli.R is given near the top of that file:

# Provides a minimal shim API to format message elements consistently
# with cli in packages that can't depend on it. If available, cli is
# used to format the elements. Otherwise a fallback format is used.

https://github.com/r-lib/rlang/blob/3d48c13d052724cd5997a730ea41bc8e6991691b/R/standalone-cli.R#L8-L10

Are there any r-lib standalone files that use suggests?

cc @lionel-

[eitsupi]

Well, the reason you see cli:: in standalone-cli.R is given near the top of that file:

I understand that but unless there is cli in the Suggests field, R CMD check will show a warning.
And if we can import cli, we don't need to use the standalone-cli.R.
So I think we need suggests field.

[eitsupi]

Are there any r-lib standalone files that use suggests?

It seems that standalone-rlang.R also needs it.
https://github.com/r-lib/rlang/blob/3d48c13d052724cd5997a730ea41bc8e6991691b/R/standalone-rlang.R#L44-L46

[jennybc]

I think what I should really be asking is: I don't think the content of standalone-cli.R has significantly changed recently. So why have folks who use it not suffered from the lack of support for a suggests field? I just feel like I'm missing some part of the rationale.

[eitsupi]

On GitHub, all packages using that file have cli on Suggests or Imports (!).
https://github.com/search?q=path%3Aimport-standalone-cli.R&type=code

Perhaps the people using this either forgot to remove cli package from Imports, or they don't have a hard time manually adding it to Suggests

[jennybc]

Now we're getting somewhere! @lionel- do you have any observations about this?

[lionel-]

I agree it makes sense to add suggests field so that the standalone file works out of the box when imported.

[jennybc]

Thanks to you both for helping advance the analysis of the problem we're trying to solve. So then ... I think this would have a companion PR in, e.g., rlang, introducing suggests fields to the standalone files that need it? Then the usethis functionality is developed to assist in placing such files (and that's what we'd test against). That's what seems like the next steps to me.

[eitsupi]

I've already created :)
#2071 and r-lib/rlang#1754

I've used these on https://github.com/eitsupi/neo-r-polars and these worked (not committed though)

[jennybc]

Another thought that this discussion has brought to my mind (but I don't know what to do about it): I wonder what fraction of packages that use standalone-cli.R (or just any particular standalone file) actually have a hard indirect dependency on cli? And I guess I also hadn't internalized that the standalone file introduces a Suggests-level dependency on cli.

But maybe cli is the wrong poster child to think about. In the sense that it's one of the packages where someone using the standalone file is pretty likely to have an indirect hard dependency on cli. standalone-purrr.R is probably a better example to keep in mind.

[eitsupi]

I think standalone-cli.R and standalone-purrr.R have completely different purposes:

• standalone-cli.R uses the functions of the cli package if it is installed (so cli should be in Suggests field), but falls back to base R if it is not installed.
• standalone-purrr.R provides functions like purrr regardless of whether purrr is installed or not, and does not change the behavior even if purrr is installed.

[lionel-]

@jennybc hmm good point. In that particular case it would be kind of odd to use standalone-cli while already having a hard dep on cli. But more generally it could make sense for a standalone file to have parts of its functionality implemented with a suggest dep, and the host package could independently have a hard dep on the same package.

So I guess ideally we don't want to add a package in Suggests if it's already in Imports?

[eitsupi]

So I guess ideally we don't want to add a package in Suggests if it's already in Imports?

use_package() would not add a package to Suggests if it already exists in Imports.

usethis/R/helpers.R

Lines 58 to 64 in 626cc0e

	delta <- sign(match(existing_type, types) - match(type, types))
	if (delta < 0) {
	# don't downgrade
	ui_bullets(c(
	"!" = "Package {.pkg {package}} is already listed in
	{.field {existing_type}} in DESCRIPTION; no change made."
	))

So in my opinion #2071 works fine.

[jennybc]

My observations really are just observations triggered by this discussion. I just meant this has me thinking through various practical aspects of standalone file usage.

For example, I hadn't fully internalized that placing standalone-cli.R requires putting cli in Suggests, in order to pass R CMD check cleanly (and I bet there are other standalone files with this same characteristic that also need suggests in their frontmatter).

[hadley]

I think it's telling that https://github.com/search?q=path%3Aimport-standalone-cli.R&type=code doesn't include any tidyverse or r-lib packages. Are we sure that this file is part of a workflow that we still recommend?

[lionel-]

@hadley It was created for rlang specifically.

[hadley]

@lionel- it's not something we'd recommend that other people use, right?

[lionel-]

I have never recommended it but I haven't stopped anyone from using it either.
Are you thinking we should actively discourage using it?

Either way it seems like a good idea to add support for suggests fields in standalone file?

[hadley]

I feel like we should be very cautious about automating our standalone file approach too much. I'm worried people are going to gravitate towards when in most cases they would be better off taking an actual dependency.