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.

[hadley]

BTW I realised that probably this should be a single option that creates a chat object:

options(
  pal_chat = function(...) {
    ellmer::chat_openai(..., model = "gpt-4o-mini")
  }
)

[simonpcouch]

Gave this a go for pal and gander and I generally do prefer this over the pair of arguments. I don't actually need to pass anything through ... in either package, though, so I'm a bit conflicted on whether this option ought to just be the Chat itself:

options(pal_chat = ellmer::chat_openai(..., model = "gpt-4o-mini"))

...instead of a function that returns the Chat:

options(pal_chat = function() ellmer::chat_openai(..., model = "gpt-4o-mini"))

I can imagine some side effects of executing e.g. ellmer::chat_openai(..., model = "gpt-4o-mini") on startup, but it'd be nice that 1) the option is indeed a "chat" as suggested by the option name and 2) the user doesn't need to add nor understand the function() boilerplate.

Feel like I might be missing something here, so I implemented it as you suggest in my first go. Neither of those PRs are merged yet, though—certainly curious to hear your thoughts.

[hadley]

Yeah if you only need an existing chat object the first should be fine. You’ll just need to make sure to clone it so you don’t end up with all the history in one chat.