Model preset API: enums vs dynamic discovery/grouping

[GeorgePearse]

Context

We discussed adding an explicit enums-based structure for model presets:

• An enum listing each high-level architecture/family
• For each architecture, an enum listing every specific preset/config

I implemented a small prototype of this idea locally, then removed it again in favor of keeping preset discovery fully dynamic (based on configs/models/*.yaml). This issue captures the tradeoffs and a possible direction if we still want a structured grouping API.

What the enums approach gives us

• IDE autocomplete / discoverability: RTMDetPreset.RTMDET_S etc.
• Type safety for library consumers and internal refactors.
• Explicit grouping (architecture -> presets) without needing to parse YAML.

What it costs

• Maintenance burden: every preset add/remove/rename requires code edits + release.
• Risk of drift from the true source of truth (configs/models).
• Closed-world feel: suggests users cannot add presets by just dropping a YAML file.

Why a dynamic approach is attractive here

• Presets are intentionally file-driven (YAML-only).
• New presets should become available automatically for:
  • SimpleRunner(model=...)
  • DetInferencer(model=...)

Potential middle-ground API

Keep strings as the primary API, but add dynamic grouping helpers:

• presets.list_model_presets() -> list of strings (already exists via MODEL_PRESETS.list())
• presets.list_model_architectures() -> list of architectures (derived from YAML fields)
• presets.list_models(architecture=...) -> list of preset names for that architecture

To make this robust, we may want to add one of:

• A required preset_meta.architecture field in each configs/models/*.yaml, OR
• Infer architecture from type (e.g. MaskRCNN -> mask_rcnn) + some special casing.

Recommendation

Treat enums as optional sugar, not the source of truth:

• If we want enums, auto-generate them from configs/models as part of CI/release tooling.
• Otherwise, prefer dynamic helpers that group presets at runtime.