Skip to content

refactor: remove ModelProviderRegistry.default and require ModelConfig.provider #590

@nabinchha

Description

@nabinchha

Summary

Final cleanup step after the deprecation cycle in #589. Collapse the entire "implicit default provider" concept end-to-end. Providers become a named list — refer to them by name, full stop. No hidden default, no YAML leakage into Python construction, no ambiguity about which default wins.

This is the architecturally clean end state that the bug fix in #588 and the deprecations in #589 are building toward.

End-state diff

Layer Today After
ModelConfig.provider str | None = None str (required)
ModelProviderRegistry.default str | None, validated, consulted by get_provider(None) Removed. get_provider takes a required str.
YAML default: key Set/read by CLI, can leak into DataDesigner.__init__ (#588) Removed from schema
dd config list "Default" column Checkmark on registry default Removed
dd config providers "Change default" mode Mode in the interactive menu Removed
DataDesigner.__init__ Reads get_default_provider_name() (#588) default_name / YAML read removed entirely
get_default_provider_name() in default_model_settings.py Exported helper Removed
resolve_model_provider_registry(providers, default_provider_name) Takes optional default Signature becomes resolve_model_provider_registry(providers)

Concrete changes

Config layer (packages/data-designer-config):

  • ModelConfig.provider: str | None = Noneprovider: str
  • Remove get_default_provider_name() from default_model_settings.py.
  • Remove default field from the CLI's ModelProviderRegistry in cli/repositories/provider_repository.py.

Engine layer (packages/data-designer-engine):

  • Drop default field from engine/model_provider.py::ModelProviderRegistry.
  • Drop check_implicit_default and check_default_exists validators.
  • get_provider(name: str) — required arg, remove None handling and get_default_provider_name() method.
  • resolve_model_provider_registry — drop default_provider_name kwarg.

Interface layer (packages/data-designer):

  • DataDesigner.__init__ — drop the get_default_provider_name() call and the default-forwarding logic introduced in bug: default model provider leaks from YAML into DataDesigner constructor #588.
  • cli/services/provider_service.py — drop set_default, get_default, and the default-tracking logic in update / delete.
  • cli/controllers/provider_controller.py — drop _handle_change_default and the "Change default provider" menu option.
  • cli/commands/list.py::display_providers — drop the "Default" column from the table.
  • cli/utils/agent_introspection.py — drop default-related fields from the introspection output.

Migration considerations

Two breaking changes that matter in practice:

1. Existing user YAMLs with default: <name>

Pydantic v2 models default to extra="ignore", so old YAMLs should load fine and silently discard default:. Worth explicitly verifying this on the CLI repository's ModelProviderRegistry schema before landing. If not, add a one-time migration on load that strips the key.

2. Existing user code with ModelConfig(alias=..., model=...) (no provider)

This becomes a Pydantic validation error with a clear message. Realistically rare:

  • All 12 built-in ModelConfigs already specify provider (asserted in packages/data-designer-config/tests/config/test_default_model_settings.py:60-94).
  • The docs example for custom configs shows provider= explicitly (docs/concepts/models/custom-model-settings.md:152, 162).
  • Anyone in the single-provider-shorthand case has a one-line fix.

By the time this lands, #589's deprecation warnings will have been visible for a release, so users will have been prompted to migrate.

Test cleanup

The two tests in packages/data-designer/tests/interface/test_data_designer.py (lines 861-867 and 901-907) currently patch get_default_provider_name as a workaround for #588. After this lands, those patches can be deleted.

Depends on

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions