Skip to content

feature: support of pydantic-settings #27

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
john-pixforce opened this issue Mar 4, 2025 · 3 comments · May be fixed by #30
Open

feature: support of pydantic-settings #27

john-pixforce opened this issue Mar 4, 2025 · 3 comments · May be fixed by #30
Assignees
Labels
feature New feature or request insiders Candidate for Insiders

Comments

@john-pixforce
Copy link

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.
@john-pixforce john-pixforce added the feature New feature or request label Mar 4, 2025
@pawamoy pawamoy added the insiders Candidate for Insiders label Mar 4, 2025
@sneakers-the-rat
Copy link

sneakers-the-rat commented Apr 15, 2025

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:

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

but both SQLModel and BaseSettings models are subclasses of BaseModel.

@pawamoy
Copy link
Member

pawamoy commented Apr 15, 2025

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
Copy link

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.

@sneakers-the-rat sneakers-the-rat linked a pull request Apr 16, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request insiders Candidate for Insiders
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants