adding default provider - #67
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Request
Short Summary
Makes
provideroptional onPrompt(...),Agent(...), and spec YAML by readingPOTATO_HEAD_DEFAULT_PROVIDERfrom the environment when no explicit provider is given. Previously every call site had to specify it; now you can set it once per deployment and omit it everywhere.Context
When using Potato Head in a service that only ever talks to one LLM provider, requiring
provider=on everyPromptorAgentis pure boilerplate. This PR pushes resolution into a central path — explicit arg wins, env var fallback, hard error if neither is set.The core change lives in
Provider::resolve()andProvider::resolve_from_py()inpotato-type. Both Python entry points (Prompt.__init__,Agent.__init__) and the spec loader now call through these instead ofProvider::from_string()directly. If resolution fails, the newMissingProviderErrortells the caller exactly which env var to set:Before:
After:
export POTATO_HEAD_DEFAULT_PROVIDER=openaiExplicit values still take precedence — env var is only the fallback. Whitespace-only values (both explicit and env) are treated as unset.
crates/potato_type/src/lib.rsDEFAULT_ENV_VAR,from_env_default(),resolve(),resolve_from_py()crates/potato_type/src/error.rsMissingProviderErrorvariantcrates/potato_type/src/prompt/interface.rsproviderfield/arg →Option<String>/Option<&Bound<PyAny>>; callsProvider::resolve()crates/potato_agent/src/agents/agent.rsproviderPyO3 arg → optional; callsProvider::resolve_from_py()crates/potato_spec/src/spec.rsAgentSpec.provider→Option<String>with#[serde(default)]crates/potato_spec/src/loader.rsProvider::resolve()instead offrom_string(); adds env-var-aware testspy-potato/python/potato_head/_potato_head.pyiproviderstubs updated toProvider | str | None = Nonepy-potato/tests/prompt/test_default_provider.pypy-potato/docs/prompts.mdIs this a Breaking Change?
No.
providerwas a required argument in both Python and the spec format; it's now optional with an explicit-wins fallback. Callers that already passprovider=continue to work without modification. The only behavior change is that omittingproviderno longer raises a type error at the call site — it raisesMissingProviderErrorat resolution time if the env var is also absent, with a clearer message than before.