feature: support of pydantic-settings

[john-pixforce]

It would be highly beneficial to add support for pydantic-settings within griffe-pydantic. Currently, griffe-pydantic effectively handles Pydantic BaseModel classes, but lacks the ability to process pydantic_settings.BaseSettings classes.

https://docs.pydantic.dev/latest/concepts/pydantic_settings/

Motivation:

pydantic-settings is widely used for managing application configurations, particularly in modern Python projects. Integrating it with griffe-pydantic would:

• Simplify Configuration Documentation: Enable automatic generation of documentation for settings models, including environment variable names, default values, and validation constraints.
• Enhance Developer Experience: Provide a consistent and streamlined approach to documenting both data models and configuration settings within Pydantic-based projects.
• Improve Code Maintainability: Ensure that configuration settings are documented alongside the rest of the codebase, reducing the risk of inconsistencies.

[sneakers-the-rat]

Same with SQLModel classes. I can't tell why the plugin doesn't already handle them actually, if maintainer points me towards a fix i'd write it :).

From what i can tell the only filtering happens here:

griffe-pydantic/src/griffe_pydantic/_internal/extension.py

Lines 55 to 56 in 187b4b8

	if issubclass(node.obj, pydantic.BaseModel):
	self._recorded.append((node, cls))

but both SQLModel and BaseSettings models are subclasses of BaseModel.

[pawamoy]

It's probably that the static analysis agent only checks for pydantic.BaseModel in the base classes, non-recursively. It doesn't try to load additional packages like SQLModel so it wouldn't know that sqlmodel.SQLModel (or whatever the path is) actually inherits from pydantic.BaseModel too.

[sneakers-the-rat]

Aha, if it's just static, then might be as simple as accepting config to look for a different base class name? Wouldn't handle any specific customizations one might want for pydantic-settings, so not to hijack the issue, but I'll try my hand at it this evening.

[qthequartermasterman]

It's probably that the static analysis agent only checks for pydantic.BaseModel in the base classes, non-recursively. It doesn't try to load additional packages like SQLModel so it wouldn't know that sqlmodel.SQLModel (or whatever the path is) actually inherits from pydantic.BaseModel too.

If this is the case (it doesn't recursively check for base classes), why does the static analysis agent successfully detect that AnotherModel is a pydantic model in the example below?

class MyModel(pydantic.BaseModel):
    id: int
    name: str

class AnotherModel(MyModel):
    asdf: str

class MySettingsModel(pydantic_settings.BaseSettings):
    asdf: str

https://github.com/qthequartermasterman/minimal-mkdocs-pydantic-bug-repo

[qthequartermasterman]

Please disregard my previous question. I understand better after reading the comments on #30 what's going on. I look forward to the follow-up PR documenting how to support pydantic-settings.

[danielgafni]

The fix suggested by @pawamoy in #41 should work here as well:

plugins:
- mkdocstrings:
    handlers:
      python:
        options:
          preload_modules:
          - pydantic_settings

[pawamoy]

Probably not, since settings inherit from the BaseSettings class, not the BaseModel one (unless BaseSettings inherit from BaseModel too). Also, rendering settings might be different than rendering models.

[danielgafni]

yes, BaseSetting is a subclass of BaseModel:

In [1]: from pydantic import BaseModel
In [2]: from pydantic_settings import BaseSettings
In [3]: issubclass(BaseSettings, BaseModel)
Out[3]: True

Also, rendering settings might be different than rendering models.

That's a good point.

[pawamoy]

Oh thanks, I didn't think it would be 😄 Then yes the suggested config might be the start of a solution 🙂