Skip to content
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

0.0.15 and 0.0.16 break multipart imports #180

Closed
mnovitsk opened this issue Oct 29, 2024 · 8 comments
Closed

0.0.15 and 0.0.16 break multipart imports #180

mnovitsk opened this issue Oct 29, 2024 · 8 comments

Comments

@mnovitsk
Copy link

0.0.12 is the latest version that doesn't seem to break or contradict the multipart class/package name.

Updating to 0.0.15 or 0.0.16 both led to the same error message of
RuntimeError: Form data requires "python-multipart" to be installed. It seems you installed "multipart" instead.

0.0.12 does not have this issue so it seems that the recent releases did not fix the issues that potentially caused the 0.0.13 and 0.0.14 releases to be yanked

@Kludex
Copy link
Owner

Kludex commented Oct 29, 2024

How can I reproduce that?

@mnovitsk
Copy link
Author

mnovitsk commented Oct 29, 2024

This occurs within the context of a FastAPI application that interacts with AWS resources and the FastAPI docs recommend using python-multipart. There are some other dependencies within the project that have sub-dependencies on the multipart library. When running pytest tests, or when building and running the API locally with python-multipart 0.0.15 or 0.0.16, the above error message is presented.

I believe the issue is likely with the exported class name multipart being in conflict with sub-dependencies of other packages on the multipart library. I can't say exactly what was done after 0.0.12, but it might have something to do with the addition of /multipart as part of the package targets or internal renaming in #166, #168, or #171.

@Kludex
Copy link
Owner

Kludex commented Oct 29, 2024

I need a way to reproduce the issue...

@mnovitsk
Copy link
Author

I don't know how to tell you how to have a project with multiple sub-dependencies that use multipart and that after 0.0.12, importing python-multipart@^0.0.15 starts throwing runtime error for class/package name conflicts, but 0.0.12 works fine.

@Kludex Kludex reopened this Oct 29, 2024
@Kludex
Copy link
Owner

Kludex commented Oct 29, 2024

I'll investigate when I have time. Thanks.

@defnull
Copy link
Contributor

defnull commented Oct 29, 2024

I think I know what's going on. For a long time, if both libraries were installed, there was a name conflict and import multipart would always return "python-multipart". This satisfied the FastAPI check, but silently broke the other library that depended on "multipart" instead of "python-multipart". With recent versions of "python-multipart", the correct import name changed to python_multipart. There is a fallback for the old import name, but that fallback is only active if "multipart" is not also installed. This is intentional. If both are installed, each import name returns the 'correct' module.

Your FastAPI version is probably too old. The new import name is supported by FastAPI>=0.115.4. You have to either pin python-multipart<=0.0.12 or update toFastAPI>=0.115.4.

@mnovitsk
Copy link
Author

I updated FastAPI to 0.115.4 and python-multipart to ~0.0.16 and the issue appears to be resolved. I guess it was mostly a perfect storm of many changes in the last few days in a couple different packages and I happened to pick the wrong combination of dependency pins

@Kludex
Copy link
Owner

Kludex commented Oct 29, 2024

Thanks @defnull 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants