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

[glyph]

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]

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]

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]

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.