-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Argument 'bases' has incorrect type #7689
Comments
Do you have a minimal, reproducible example? We didn't change much: v1.10.12...v1.10.13 |
I will give it a shot. As context, these are the libs in HA:
We can already confirm from reports that these are failing:
I know this isn't an example, but all these libs raise problems when used with 1.10.13, and not with 1.10.12. I'll get back with an example |
We also looked at the changelog and were puzzled on why this suddenly fails |
Apparently running tests of |
Seems to only affect the systems we have binary wheels for ie i686/x86_64 |
pydantic-1.10.12 doesn't seem to have the problem, but I think they were built with cython 0.29.x Maybe cython 3.x issue? |
pydantic v1 should be built with cython 0.29: Line 3 in 8822578
|
I think that won't get used until its in |
If I create a
It uses cython 0.29.32 |
Without the |
makes sense. @hramezani could you work on another patch release using the right cython when building. |
Edit: saw above comment after I opened the PR. Closed the pr |
Hi, I've tried to reproduce this using and Output of
I just tried creating a model and doing some validation and it ran fine - but the exception occurs on this line which is just creating a model. I'd really like to be able to reproduce this, then confirm it's fixed before creating a new release. |
I also tried running pydantic 1.10.13 inside alpine inside gitpod to use musl binaries, and again - no error. |
same here, tried do install dietpi's octoprint on a pi 2 zero Screen output |
Solves #4893 by working around pydantic/pydantic#7689
In case it helps since (a) I spotted this issue reading the OctoPrint release notes, and (b) I just spent a some time debugging a mysterious issue with In the case of the problem I was debugging (metadata In the Glasgow project case I initially worked around it by catching the return type received was the "wrong one" and fixing it up before using it in the Glasgow project code; but the final fix merged ended up monkeypatching in the newer code for importlib metadata Ewen |
It gets weirder. After pinning pydantic to 1.10.12 in my project (OctoPrint) to solve this problem, and confirming it against various deployment scenarios, I got reports that even that won't work on RaspberryPi OS Bookworm with Python 3.11.2. So I ran some tests:
I had to downgrade to pydantic 1.10.10 in the last scenario to make things work there again. At this point I have to say that I'm beyond confused by this particular issue but hope that the above findings can help in any way to get to the bottom of this. |
We have also seen reports of 1.10.12 not working for some reason. In our case that could've been caused by custom integrations (which have their own dependency), but in earlier tests, installing 1.10.12 would fix the issue, but in some cases it just doesn't |
Well, if anything at least it fits spooky season 🎃👻 Currently running some more tests to collect some more data points. |
I got some more results. On a whim I tried a stock Debian Bookworm image with an added config to use piwheels.org as additional index for pip, and THAT resulted in a reproduction. My test setup can be found here: https://gist.github.com/foosel/80b22908c008c063b85c819aee12c5ad I'm testing with a really minimal from pydantic import BaseModel
class TestModel(BaseModel):
foo: str = "bar"
if __name__ == "__main__":
test = TestModel()
print(test) And here's the results against Debian Bookworm with Python 3.11.2 on arm32v7:
So the issue as observed for pydantic 1.10.11 through 1.10.13 on Raspberry Pi OS Bookworm with Python 3.11.2 seems to stem from the binary wheels provided by the piwheels project. Piwheels comes preconfigured as additional index URL on RPi OS, and telling pip to use piwheels als additional index via A look at the package page reveals that piwheels only has wheels available from 1.10.11 onward, which means 1.10.10 would be taken from pypi, so something is apparently up with the builds on piwheels against Python 3.11. I wonder if the packages compiled by piwheels also ran into the aforementioned problem of accidentally being compiled against Cython 3? edit In any case, someone from the pydantic team with the proper authority of a maintainer should maybe request removal of the affected packages from piwheels as described in the FAQ: edit I took the liberty to at least report the problem to piwheels: piwheels/packages#396 |
Updating from 1.10.12 to 1.10.13 fixed the problem for me. |
I see this issue while testing maison. |
Testing of
|
While the smart people are working on the proper fix for this, is there a simple workaround that we can use? |
Initial Checks
Description
So last night 1.10.13 got released. And apparently it breaks on runtime,
The context is that there are some integrations in HomeAssistant that use pydantic, and they all seem to raise this issue when 1.10.13 is installed. This isn't raised in 1.10.12 (home-assistant/core#101044). Linked issue on the HA repo (home-assistant/core#101042).
Some of the libs used are https://github.com/frenck/python-vehicle and https://github.com/frenck/python-radios
Example Code
No response
Python, Pydantic & OS Version
Affected Components
.model_dump()
and.model_dump_json()
model_construct()
, pickling, private attributes, ORM modeThe text was updated successfully, but these errors were encountered: