Skip to content

Import name conflict between two packages #818

Closed
@defnull

Description

@defnull

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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions