SQLModelConfig is not publicly exported while SQLModel annotates model_config with it, rejecting public ConfigDict/dict spelling under ty

[zkewal]

SQLModel annotates model_config: SQLModelConfig (sqlmodel/main.py), but SQLModelConfig lives in the private sqlmodel._compat module and is not exported from sqlmodel.__init__. As a result, typed application models cannot satisfy the annotation with any public spelling: ty rejects both the plain-dict and the pydantic ConfigDict forms, while mypy accepts both.

Environment: pinned sqlmodel 0.0.38 (latest checked 0.0.42), pydantic 2.13.4, ty 0.0.80.

Evidence:

• sqlmodel/_compat.py defines class SQLModelConfig(BaseConfig, total=False) where BaseConfig = ConfigDict, adding table and registry keys.
• from sqlmodel import SQLModelConfig raises ImportError; only from sqlmodel._compat import SQLModelConfig works.
• ty 0.0.80 reports invalid-assignment for both model_config = {"from_attributes": True} (dict[str, bool] vs SQLModelConfig) and model_config = ConfigDict(from_attributes=True) (ConfigDict vs SQLModelConfig).
• mypy 1.20.2 reports no issues for either spelling.

Minimal reproduction (any non-table response model):

from pydantic import ConfigDict
from sqlmodel import Field, SQLModel


class Widget(SQLModel, table=True):
    id: int | None = Field(default=None, primary_key=True)
    name: str


class WidgetPublic(SQLModel):
    id: int

    model_config = ConfigDict(from_attributes=True)

Run ty check on the file: invalid-assignment on the model_config line. Replace with the plain-dict form and the same error appears with dict[str, bool]. mypy is clean in both cases.

Requested fix: either export SQLModelConfig from sqlmodel.__init__ (so apps can use the same spelling sqlmodel itself uses at main.py), or align the public model_config annotation so the documented public ConfigDict/dict spellings type-check. Happy to test a patch against ty 0.0.80.

[artur282]

Confirmed against main — this is a real gap, not something wrong on your side:

• sqlmodel/_compat.py defines class SQLModelConfig(BaseConfig, total=False) where BaseConfig = ConfigDict, adding the sqlmodel-only table and registry keys.
• sqlmodel/main.py imports it (line 61), annotates model_config: SQLModelConfig (line 564) and assigns model_config = SQLModelConfig(from_attributes=True) (line 853).
• sqlmodel/__init__.py has zero occurrences of SQLModelConfig (and zero of _compat), so from sqlmodel import SQLModelConfig can only fail.

That leaves three spellings that work today:

1. The spelling sqlmodel itself uses (runtime-safe, private module):

from sqlmodel._compat import SQLModelConfig


class WidgetPublic(SQLModel):
    id: int

    model_config = SQLModelConfig(from_attributes=True)

Here the assigned value is the annotated type, so there is nothing for a checker to flag.

2. Keep the public ConfigDict spelling and acknowledge the annotation mismatch:

from pydantic import ConfigDict


class WidgetPublic(SQLModel):
    id: int

    model_config = ConfigDict(from_attributes=True)  # type: ignore[assignment]

3. Avoid the attribute entirely if the flag is only needed in one place: WidgetPublic.model_validate(row, from_attributes=True).

Why ty complains on (2) and mypy does not: the base class annotates model_config with a total=False TypedDict, and neither the plain dict literal (dict[str, bool]) nor ConfigDict is assignable to it; mypy is simply more permissive about that particular assignment.

Minimal upstream fix I would suggest — export the same typed config the library already uses internally, in sqlmodel/__init__.py:

from sqlmodel._compat import SQLModelConfig as SQLModelConfig

plus a small test asserting that from sqlmodel import SQLModelConfig works and that the exported name is the type used by the model_config annotation. Widening the inherited annotation to ConfigDict instead would lose the table/registry keys, so exporting is the smaller backwards-compatible change. Happy to open that PR if maintainers prefer this direction.

[Raymondo97]

I can confirm this issue as well. In my projects, I'm using sqlmodel>=0.0.38, with pyright>=1.1.411 and ruff>=0.16.3. These errors have bothered me for a while. Until now, I've just ignored the warning of using a private import in my code.

I'd love for it to be moved to, or exposed from a more public location in the package's exports. But I'm open to whatever solution the maintainers might recommend.