Description
Problem description
I was recently made aware of a name conflict between multipart and python-multipart. Both install themselves as multipart
, which causes difficult situations for framework developers now that Python 3.13 removes cgi
and the official docs mention multipart
as a replacement. I have very good reasons to not just rename multipart
into something different and the maintainers for python-multipart
also have denied similar requests. There are plans to absorb python-multipart
into Starlette (its primary dependent) so the problem might go away on its own, unfortunately without a timeline given.
I'm aware that pypi cannot prevent such conflicts for several (mostly technical) reasons. I'm here to ask for ideas how to solve this in a way that does not make things even worse in the long run.
So, first idea: I could package two files with identical content named multipart.py
and multipart_fallback.py
into the same wheel and sdist archive and tell users to import the fallback if they run into conflicts. Pro: Easy to maintain on my side. Con: This pollutes the namespace even more and does not feel like the right thing to do.
Second idea: Create a second project named multipart-fallback
that depends on multipart
and installs a skeleton multipart_fallback.py
file with some exec
or importlib
magic. Pro: Opt-in solution. Con: Harder to maintain, feels like a hack.
Third idea: Do nothing and tell others to vendor multipart.py
if they have to. Pro: Not much. Con: A pain for everyone involved.
More ideas?