Name clash with multipart package.

[tomchristie]

I don't especially mind that both multipart and python-multipart exist on PyPI, but it's a bit awkward that they both also install as multipart.

I've already managed to bump my head on this, and couldn't understand why the signature for multipart.MultipartParser wasn't as expected having had both packages installed at some point.

Although I much prefer the plain multipart name I wonder if it's worth considering something like multipartparser?

Alternatively we don't worry about it for now, and consider something later if it's an issue. Not sure.

[tiangolo]

I would like to second this. It's quite hard to detect when it happens, it took 3 of us for a whole day (or more) to finally discover we had both packages installed. I was about to call a server exorcist 😂

Of course, it was a bug in our code to have both installed, but the fact that sometimes one is used and some times the other for the same multipart makes it especially difficult to debug.

Would you consider changing the import name as @tomchristie suggests? 🙏

[Kludex]

I'm not fixing this.

My intention is to maintain this package till we merge the code to Starlette.

[tomchristie]

@Kludex Appreciate a concise & clear response. 🌟

[henryiii]

FWIW, I'd recommend renaming the import to python_multipart. It's not a good idea to name your import to something that you don't own on PyPI. If someone has the PyPI package multipart, it's quite reasonable for them to name the import multipart. You don't own the PyPI name, so I think you should use the name you do own.

Note that the official CPython docs recommend multipart (the Python package) as the replacement for the removed-in-3.13 cgi module, so more packages are going to start requiring that one.

[Kludex]

Why does CPython recommends that?

[henryiii]

It's here: https://docs.python.org/3.12/library/cgi.html

[ubernostrum]

This issue was opened six years ago. If that has not been enough time for you to figure out how to merge this into Starlette, then it seems extremely unlikely it will ever merge.

And as long as this name conflict situation goes on, it causes pain and brokenness to people who don't deserve it and didn't ask for it, and harm to the overall Python community and its reputation. This also causes harm to your reputation as an individual, the reputation of the projects you work on, and the reputation of the company you work for.

Please do the right thing, reconsider your course here, and change the module name to remove the conflict.

[henryiii]

FYI, let me know if you want me to help with the solution I suggested... somewhere, not this thread apparently. That would be to rename the import to python_multipart but provide a custom importer that will cause import multipart to import python_multipart instead as long as there isn't a multipart module installed, and produce a warning asking users to update their imports to python_multipart. I think I've done enough import shanagans with editable installs that I have a moderate idea of how it would work. This would provide a forward path for users, and in the long run would help users that expect import names and package names to match.

But I don't want to spend time helping with a solution if you are not interested in one.

[Kludex]

@henryiii Is it possible to have a fallback to multipart import? If it is, and you have time, I'm happy to review a PR.

My only concern is that I want to bring security fixes to users that are stuck on old versions of packages that depend on this project.

I'm locking this issue. Open source has been a bit too rude to me lately.