include `withr::local_()`, `withr::with_()` setters

[maxheld83]

as per https://withr.r-lib.org/reference/with_.html

I've tried building a withr::local_()/withr:with_() for options in:

https://github.com/dataheld/elf/blob/d4306269079278b446840c706687d265072190bd/R/options.R#L1-L23

but settled for an opt_set_local2() based on withr::defer(), as you advise in the docs.

I noted that the semantics of options and withr don't quite match, though I'm not quite sure what I meant by that.

[maxheld83]

for more rationale (TL,DR: I'm lazy and a sucker for syntactic sugar 🍭), see discussion in dataheld/elf#5

[maxheld83]

oh and I'm happy to pitch in a PR, if you find this useful @dgkf.

I'm guessing one problem could be just naming around options::local_opt()/options::with_opt()

• either name clash with withr::*_options(), or confusingly similar (opt/options)
• the withr arg names (old/new) might sit awkwardly inside options.

So maybe as you originally suggested just an options::opt_set_local2() based on withr::defer() would be more elegant.

[dgkf]

Thanks for sharing your experience! I was originally reluctant to include withr because options has a very slim dependency footprint and I wasn't exactly sure what functionality it added. I probably should have investigated a bit more - I didn't realize how slim withr's footprint was.

I think these can be introduced. They definitely help to mitigate some on.exit() traps.

Just to try to summarize the open questions before this gets added:

• If withr is introduced as a dependency, do we even need the current on.exit() approach?
  I'll reach out to the withr team to hear whether they see any reason why we'd want to keep a base version alongside a withr version. I think the only situation that would be affected is if a user is attaching their own attributes to an environment (that might mask the withr_handlers attribute, which I believed is used to house a reg.finalizer() callback.)
• TBD: If we want both, then we'll need to make sure we have disambiguated names to avoid withr confusion/conflicts.
• Decide whether we want to match a withr-style function signature or keep the interface more consistent with options.

[dgkf]

Another idea that came to mind. Maybe it would be sufficient to provide a helper for constructing withr-style mappings of options and their values. I'm imagining something like:

withr::with_options(
  options::make_opts(x = 1, y = 2),  # open to better name suggestions!
  ...
)

In this scenario, options::make_opts(x = 1, y = 2) is a shorthand for producing the appropriate package options list:

list(
  package.x = 1,
  package.y = 2
)

It's not as out-of-the-box, but it would make it far easier to use options alongside withr.

[tdeenes]

I second that approach, and would argue against making withr a required dependency.