feat: add declarative Outfit files for provider config - #3
Merged
Conversation
Add an Outfit file: a flat, Dockerfile-style description of a single opencode provider selection (PROVIDER/FAMILY/MODEL), applied in one command. Keywords are case-insensitive with UPPERCASE canonical, and `#` comments are supported inline and full-line. - `oc-config apply [path]` applies an Outfit, defaulting to ./Outfit; it shares the existing add pipeline via applySelection. - `oc-config export [-p name]` reconstructs an Outfit from the current config, naming a FAMILY when the configured models match one. - Document the format in docs/outfit-file.md and move the llama.cpp guides under examples/, each with a ready-to-apply Outfit. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add tests for the reverse family lookup (`matchFamily`) and the `export`/`apply` branches: model-only fallback when no family matches, keeping both FAMILY and a non-default MODEL, multi-provider selection (error / -p / unknown -p), empty config, and apply error paths. Raises total coverage from 87.7% to 89.9%. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Extend the Outfit syntax with two optional instructions that map to the existing `--context` and `--base-url` flags: - CONTEXT <size> sets the model's context window (128k, 1m, 200000). - BASEURL <url> overrides the provider API base URL; URL, BASE-URL, and BASE_URL are accepted as aliases. `apply` threads both through the shared add pipeline. `export` recovers them too: it records a BASEURL only when it overrides the catalogue default, and a CONTEXT only when the exported models agree on one value, so it never invents data. The llama.cpp examples now set a matching CONTEXT in-file instead of a follow-up add. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
Add an
Outfitfile: a flat, Dockerfile-style way to capture one opencode provider selection and apply it with a single command.Summary
Outfitfile format —PROVIDER/FAMILY/MODEL/CONTEXT/BASEURLinstructions, one provider per file. Keywords are case-insensitive (UPPERCASE canonical), with#comments inline or full-line.CONTEXTandBASEURLmap to the--contextand--base-urlflags (withURL/BASE-URL/BASE_URLaliases), so an Outfit can express everythingoc-config addcan.oc-config apply [path]to apply an Outfit, defaulting to./Outfitso a bareoc-config applyworks. It reuses the existingaddpipeline via a sharedapplySelection, so config merges behave identically.oc-config export [-p name]to reconstruct an Outfit from the current config, naming aFAMILYwhen the configured models match one and otherwise the specificMODEL.docs/outfit-file.md(end-user oriented) and move the llama.cpp guides underexamples/, each now a directory with a README and a ready-to-applyOutfit.Implementation details
oc-config add, which kept the parser small and the apply path a thin wrapper over existing logic.exportis a best-effort inverse ofwriteConfig:loadConfigStatereads back each provider's model keys,options.baseURL, and per-modellimit.context;matchFamilycollapses a known model set to its family name. It records aBASEURLonly when it overrides the catalogue default, and aCONTEXTonly when the exported models agree on a single value, so it never invents or guesses data.--base-url(feat: allow API base URL override via flag or env var #1) and--context(feat: add --context flag to set model context window #2) work; the Outfit keywords reuse those sameselectionfields and the example guides now set a matching context window in-file.