Skip to content

Pass configs via dependency injection into model classes (BaseModelConfig-only; dict supported) #930

@cpaniaguam

Description

@cpaniaguam

Base branch

Implementation work for this issue on: rlssm-class-make-model-dist.

Philosophy / non-negotiables

  • The authoritative config object used by any model instance MUST be a subtype of
    BaseModelConfig (e.g., Config, RLSSMConfig, and future family configs).
  • Users MAY pass a dict for configuration (project decision), but dict must be
    treated as an input convenience only:
    • normalize/coerce the dict into the appropriate BaseModelConfig subtype ASAP,
    • validate it,
    • and then store/use only the typed config object for the remainder of model construction.

What should change

1) Move build policy into config families

Each model-family config class must implement its own _build_model_config(...)
(family-specific builder), rather than relying on one centralized builder in HSSMBase.

The family builder is responsible for:

  • resolving defaults (from_defaults(...)),
  • normalizing user overrides provided as dict into the family config type,
  • resolving precedence rules (e.g., choices= argument vs config-provided choices),
  • and returning the final, validated config object (still a BaseModelConfig subtype).

2) Model instances must keep config state

Each model instance must keep a reference to the exact config object used to build it
(e.g., self.model_config: BaseModelConfig or similar), and distribution-building should
read from that object consistently.

Avoid having the “true config” split between:

  • self.model_config and a separate set of copied scalar attributes,
    except where absolutely required for backwards compatibility.

Dict compatibility requirement

The DI refactor must preserve the ability to pass config overrides as a dict, but the
dict must be normalized into a BaseModelConfig subtype before use.

Code references (current state)

Metadata

Metadata

Assignees

No one assigned

    Labels

    dependenciesPull requests that update a dependency file

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions