feat: spin out non-mainstream providers into a rig-providers crate

[Cupnfish]

• I have looked for existing issues (including closed) about this

Feature Request

I think if we provide a rig-providers as a new crate, other projects in the community can integrate it well, which would definitely be beneficial for project maintenance. I looked into existing projects in the community, such as llm, which appears to have many features, but in reality, a lot of them are not implemented.

Motivation

I want to build a chat GUI software llm by myself for fun, but I haven't found a suitable package. Rig is too big for me, I don't need so many proxy functions. The current core doesn't seem streamlined enough, and some parts could be developed as a separate crate.

Proposal

It feels like splitting the providers module into a separate crate would solve the problem

Alternatives

This is just a wish I have out of a desire for a streamlined providers package, hoping that rig can separate this module as a high-quality providers library that the community can directly use

[0xMochan]

This is something that came up internally. It's sorta tricky bc ideally, we want something straightforward for people to install cargo add rig-core tokio and then u can run an example. it would end up changing to cargo add rig-core rig-providers tokio for things to continue.

I think something like keeping atleast openai in rig-core and perhaps anthropic + gemini in core and we can throw the other providers in an side-crate would be suitable. I will say, I don't see how a rig-providers crate would be usable outside the community unless we spun out the completion method as it's own thing and added some stuff for rig-core to be an extra feature which would add some maintenance burden to the team for some unknown benefit. The main benefit of rig's shared traits and structs is to generalize method with each of the providers.

I definitely can see how the inclusion of abstraction layers like agents w/ tool calling sorta can be seen as a heavier integration so something where the providers can be used standalone is enticing. From our POV, if you desire a closer connection to the LLM interface, the CompletionModel trait via .completion method is a direct way to talk to the LLM with no interpretation of embeddings, RAGing, tool calling, etc. The only transformation that occurs is the direct generalization from the provider's message model to the generalized one.

---

TL;DR: It's def. on our radar with having a rig-providers. In terms of having rig-core being an optional features for said side-crate, it's likely not our highest priority.