package option for elmer extensions

[simonpcouch]

Been working on a couple BYO-key elmer extensions that aim to support any of the chat_*() backends from elmer, like this one or this one. For each of them, I assume that folks are likely to use the same provider and model most of the time, so I support toggling those arguments using package-level options and recommend setting them in .Rprofile, like:

options(
  .pal_fn = "chat_openai",
  .pal_args = list(model = "gpt-4o-mini")
)

or:

options(
  .ensure_fn = "chat_openai",
  .ensure_args = list(model = "gpt-4o-mini")
)

While I can see the value in having different tools hook into different models by default, I think it'd also be nice to have more general .elmer_fn or .elmer_args options that would apply across extensions. Would yall consider documenting some "recommended" interface for extension options that include more general options like those?

[hadley]

Maybe we could have a chat_default() that used a user-supplied default? (Or maybe picked automatically based on presence of env vars?)

@jcheng5 what do you think?

[hadley]

@simonpcouch I think I'll probably export the provider classes, and then some generic way to create a chat object from a provider. Then we could possibly have ellmer::set_default_provider() which packages could use. I do wonder a little bit about making this too easy since this does effectively give packages the ability to spend money on your behalf, so we might need to think about some explicit acknowledgment workflow.

[simonpcouch]

Ooo I do like this interface. The hesitancy re: spending money without user consent definitely makes sense and I'm happy to work with that acknowledgement workflow; even if a user of pal/ensure/gander has to respond to a y/n prompt, this is an easier setup workflow than setting those package options in .Rprofile.