Lexically-scoped verbosity

[lionel-]

The behaviour for soft-deprecation verbosity in unit tests was originally intented to depend on whether the soft-deprecated function is called from the tested package or downstack:

• If called from the tested package, the default verbosity is set to "warning"
• If called from a dependency, it is set to "quiet"

This conditional verbosity is implemented in deprecate_soft() via the envvar TESTTHAT_PKG which is set to the package being tested. Unfortunately, this default stopped working correctly with testthat 3e because it hardcodes verbosity to warning. The problem is that verbosity is currently set via a global option whereas we really want some sort of lexical scoping instead.

I think it's a good idea to let testthat set the lifecycle verbosity, but we need a lexically scoped mechanism. I see two options. The simplest is to allow defining verbosity with a local binding:

local_bindings(
  .lifecycle_verbosity = "warning"
)

This is not practical when the deprecation is signalled from helpers though, because the calling environment of these helpers will not have that binding in scope. What we really want is to set verbosity for the whole namespace. So we could provide a custom tool for this:

lifecycle::local_verbosity(
  rlang = "warning",
  purrr = "warning"
)

testthat would use this to enable warnings for the package being tested instead of setting the global option.

We could also frame the behaviour with the global environment in terms of this mechanism. You could disable this behaviour like this:

lifecycle::poke_verbosity(global = NULL)

This would be less risky than using the global options(lifecycle_verbosity = "quiet") which silences all warnings without distinction.

What do you think @hadley?

[hadley]

I like the lifecycle::local_verbosity() approach best

[lionel-]

One issue with this approach is that snippets run from test files directly in the REPL will be scoped from global rather than the package. So direct evaluation and devtools::test() might produce different results.

A possible workaround would be for pkgload to record the last package that was loaded and treat the top env of the global env to be the namespace of that package.