Feature: Multiple Models Per Version - #497
Conversation
|
Status: ❌ Request Changes — Gist: https://gist.github.com/jarbasrf/3c6059e57956669c2be838307254f445. Resumo: The PR changes |
|
Status: ❌ Request Changes — Gist: https://gist.github.com/jarbasrf/fbfdc78d9c9c21ed3ef62cf90bd30955. Resumo: The artifact was written to the requested path. The main remaining issue is that |
|
Status: ✅ Approve — Gist: https://gist.github.com/jarbasrf/f53f7a4dedd198da2b3b86edf18fabea. Resumo: The previously reported |
|
Status: ❌ Request Changes — Gist: https://gist.github.com/jarbasrf/e547be780a0c8fbda40ed65805fc6ad0. Resumo: The prior MMPV issues remain resolved, but current head adds a core |
|
Status: ✅ Approve — Gist: https://gist.github.com/jarbasrf/25192f4b64448ea98d5b32b989275840. Resumo: The prior |
|
|
# Conflicts: # CHANGELOG.md # roboflow/__init__.py
# Conflicts: # roboflow/__init__.py
Rebased #510 onto the merged MMPV surface (#497), deduplicating against its canonical v2 trainings plumbing instead of carrying parallel implementations: - rfapi.get_train_recipe — GET .../v2/trainings/recipe (schema + editable template) for a model type. New; no #497 equivalent. - rfapi.create_training_v2 gains train_recipe (camelCase trainRecipe body key) and business_context; replaces this branch's former parallel rfapi.create_training. rfapi.list_version_trainings/get_version_training are dropped in favor of #497's list_trainings_for_version/get_training. - Version.describe_train_recipe(model_type) — SDK wrapper for the describe endpoint. - Version.create_training gains train_recipe/business_context; replaces the former Version.start_training. Keeps the pre-network guard (train_recipe requires model_type — recipes are minted per model type) and folds a top-level epochs into the recipe's hyperparameters via util.train_recipe.fold_epochs_into_recipe (recipe epochs wins; missing hyperparameters key is created), because the server resolves dense-filled recipe epochs ahead of the body value. Version.list_trainings/get_training are dropped: #497's trainings()/Training.refresh() cover them. - Tests re-homed onto the canonical functions; #497's exact-kwargs create assertion extended with the two new pass-through kwargs. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- roboflow train recipe -p <project> -v <N> -m <model_type> — print the recipe schema and ready-to-edit template as JSON (both output modes). - --train-recipe on train start (and the bare train callback): inline JSON or a curl-style @file reference. Routes through the canonical rfapi.create_training_v2 (from #497) and prints the new trainingId instead of blocking. Structured errors, all before any network call: unreadable @file, invalid JSON, non-object JSON, and a missing model type (recipes are minted per model type). - --epochs is folded into the recipe's hyperparameters unless the recipe already sets epochs (the server resolves recipe epochs ahead of the body value). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
CHANGELOG entry reconciled with #497's 1.4.0 MMPV section: #510 now describes only what it adds on top of the canonical surface — the recipe describe endpoint, train_recipe/business_context on Version.create_training, the epochs fold, and the CLI recipe surface. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Code and PR description are LLM-generated.
MMPV support: first-class Training / TrainedModel + backwards-compat
Adds DNA-style multi-model-per-version support to the SDK, consuming the new v2
external trainings endpoints.
Companion PRs:
feature/mmpv→main(MCP client)feature/mmpv→main(SDK client)What this adds
roboflow/core/training.py— newTrainingandTrainedModelobjects.A version owns many trainings; a training owns one or more models (NAS owns
many).
TrainedModel.predict()infers by<ws>/<model-slug>;.download()pulls weights by model id.adapters/rfapi.py— v2 trainings adapter(
list_trainings_for_version,get_training,create/cancel/stop_training_v2,get_model_weights_url) mirroring the MCP'srf_api.py1:1. Thelegacy-vs-MMPV branch lives on the backend, never in the client.
Versiongains.trainings(),.models(), and a back-compat.modelproperty that resolves the sole model and refuses to guess when a version
owns several — raising with a CTA to
version.models().Backwards compatibility
Old installs keep hitting the frozen v1 routes, which the backend now makes
MMPV-aware. Single-model MMPV versions still work for metadata,
train()poll-reads, and weights download; only
predict()on MMPV is the deliberatecasualty (requires the new
<ws>/<model-slug>id).Tests
tested e2e with both new and old versions of package and verified expected behavior/graceful-degradation on both legacy and MMPV versions on staging.
Link to Gist with the e2e smoketest run on the
kaiplacestaging workspace: https://gist.github.com/mkaic/2d19b05f4f4c253bbca2ef9aca7746f4Results of running that script against the currently deployed staging API: