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

Name conflict with https:/Kludex/python-multipart #53

Open
glyph opened this issue Sep 19, 2024 · 2 comments
Open

Name conflict with https:/Kludex/python-multipart #53

glyph opened this issue Sep 19, 2024 · 2 comments
Labels
FAQ Solved or not a bug, but kept open for visibility

Comments

@glyph
Copy link

glyph commented Sep 19, 2024

As filed in twisted/treq#399, these packages both define import multipart. This one is older, but, it seems, less popular. One of them should rename its import name.

@defnull
Copy link
Owner

defnull commented Sep 19, 2024

Interesting, I did not know that. But I will not rename this module for several obvious reasons:

  • A change would break all applications or libraries currently depending on it.
  • The current import name matches the package name on pypi, which is what most users expect.
  • This project was first, as you already mentioned. Popularity should not be a factor.
  • The python-multipart authors must have known about this project and still opted for a conflicting package name. That's on them.
  • There are plans to merge python-multipart into starlette, so the problem may go away on its own.
  • This project is mentioned in the official python documentation as an alternative to the deprecated and soon to be removed cgi.FieldStorage parser.
  • This module can be easily vendored (single-file, no dependencies) if you absolutely have to depend on two multipart parser implementations in the same project.

twm added a commit to twisted/treq that referenced this issue Sep 19, 2024
@defnull defnull added Request FAQ Solved or not a bug, but kept open for visibility labels Sep 20, 2024
@defnull
Copy link
Owner

defnull commented Sep 20, 2024

The naming conflict caused by the python-multipart authors is definitely affecting people. Both starlette and FastAPI (based on starlette) have detection code that checks for this conflict at runtime and shows a detailed error massage. There are also warnings in their documentation explaining how to fix the issue. I did not know that those two very popular libraries depend on python-multipart, that probably explains why the download stats for it are so high.

I just proposed to the starlette project to switch to multipart or vendor it. They planned to drop the dependency on python-multipart anyway, so I took that opportunity. The new non-blocking parser in multipart 1.0 would actually make the switch possible. Edit: Nah, python-multipart is from the starlette maintainer, that won't happen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FAQ Solved or not a bug, but kept open for visibility
Projects
None yet
Development

No branches or pull requests

2 participants