-
Notifications
You must be signed in to change notification settings - Fork 33
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
BaseSettings
from pydantic-settings
can't be used as a dependency
#250
Comments
Thanks for reporting this! I'll try to fix it this Friday. Really nice minimal reproducible sample too! |
Only did a bit of a poke, but nothing jumped out at me as to a cause. Using a If you point me at a theory or cause, I might have a chance to get a PR up for you to look at. |
I guess it's trying to wrap BaseSettings (to build its own wrapper around the model so that you could perform migrations over it) which Cadwyn is not supposed to do. _wrap_pydantic_model has special casing for BaseModel and I guess it should have the same special casing for BaseSettings. But this is just a theory. |
Minimal fix in def __getitem__(self, model: type[_T_ANY_MODEL], /) -> type[_T_ANY_MODEL]:
if (
not isinstance(model, type)
or not lenient_issubclass(model, BaseModel | Enum)
or model in (BaseModel, RootModel, BaseSettings)
):
... But this requires importing |
How about an optional import? I.e. import in try-except block and if failed to import — |
May I also ask (just for personal statistics) where do you use Cadwyn and how well does it fit your use case? Anything missing or confusing? |
Evaluating it right now for our FastAPI app that badly needs a good versioning story. Tried throwing it right at our codebase and this is the first hurdle I found. As for features, any thoughts about non-date version numbers? As long as they stay sortable. |
Could do, will give that a try and a test case. I think I'd like to understand why that special case is needed, though. |
Nice! Ping me if you need any features or help. As for non-dates — I wanted to do this for a while too. I can implement it either this week or next week depending on my availability. But note that they'll need to be fully lexicographically sortable. I.e. pure semantic versioning wouldn't fit in the first implementation. But I'm open to add that as well. |
First reason I thought is transitioning from our simple |
Sure! I can do that soon. |
I began working on the non-date versions but found a pretty bad case: "v10" < "v9". So we can't just handle them as regular strings. I'll do my best to add url-based versioning and v-prefixed numbers for versions. |
Can take discussion to a different issue if you'd like. If it helps understand our case, we could work with being able to mark one "legacy" version like |
Describe the bug
change_version_of_annotation
doesn't handleBaseSettings
frompydantic-settings
.To Reproduce
Expected behavior
The root endpoint should return
{"foo": "bar"}
, instead I get the following traceback:I've tried a few different ways of setting up the dependency, but every time cadwyn hits it I get a similar error.
The text was updated successfully, but these errors were encountered: