Name conflict with https://github.com/Kludex/python-multipart

defnull / multipart

A fast multipart/form-data parser for python

https://multipart.readthedocs.io/

MIT License

135 stars 33 forks source link

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

Closed glyph closed 1 month ago

glyph commented 2 months ago

As filed in https://github.com/twisted/treq/issues/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 commented 2 months ago

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.

defnull commented 2 months ago

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.

defnull commented 1 month ago

I'm happy to announce that this should no longer be an issue. The python-multipart project changed its import name to python_multipart and both Starlette and FastAPI support the new import name. There is a clever fallback if multipart.py is not installed to support legacy apps, but that will also be removed in a couple off releases once most apps have updated their import statements.