fix: use alternate scheme for importing multipart

[henryiii]

This is an alternate attempt at #166 that allows a user to install the package and import it in a single Python process (not recommended, but Google Colab basically requires this to install anything).

This has the following pro's:

• Doesn't rely on the import system loading a .pth file, meaning it can be hot swapped
• Editable installs are supported (ironically, editable installs use the same .pth and custom loader that the original attempt did, but Google Colab users don't do editable installs!)
• Less invasive on import multipart if multipart is not installed.

And the following con's:

• Only handles filesystems; if the imports are not from file systems, it will not work (it will have the old collision behavior in that case).
  • This could be fixed if it's a problem, I think, but I think this is fine unless you have users loading both packages from a non-filesystem (like a zip).
• A bit more invasive on multipart, specifically requiring that package not be moved to a module structure while this workaround is in place.

I also added a wrapper script for nox like the other scripts in /scripts.

[Kludex]

@defnull you good with the last point on the cons?

[defnull]

I have no plans to turn multipart.py into a package anytime soon. Since this is not a permanent thing but just a temporary workaround, I'm absolutely fine with that :)

[defnull]

A quick test looks promising:

$ python3 -mvenv venv
$ venv/bin/pip install git+https://github.com/henryiii/python-multipart.git@henryiii/fix/importer
[...] Successfully installed python-multipart-0.0.13

$ venv/bin/python -c "import multipart; print(multipart.__file__)"
<string>:1: FutureWarning: Please use `import python_multipart` instead.
/home/.../venv/lib/python3.12/site-packages/multipart/__init__.py

$ venv/bin/python -c "import python_multipart as multipart; print(multipart.__file__)"
/home/.../venv/lib/python3.12/site-packages/python_multipart/__init__.py

$ venv/bin/pip install multipart
[...] Successfully installed multipart-1.1.0

$ venv/bin/python -c "import python_multipart as multipart; print(multipart.__file__)"
/home/.../venv/lib/python3.12/site-packages/python_multipart/__init__.py

$ venv/bin/python -c "import multipart; print(multipart.__file__)"
/home/.../venv/lib/python3.12/site-packages/multipart.py

[Kludex]

I'll get a release with this when I have time.

[defnull]

This also works as expected in Google Collab:

The last edge case "conflict while importing from zip-files or other non-file-system imports" should be exceptionally rare and the important parts of this PR (being backwards compatible and printing a warning) should still work, so it's still an improvement over the current state.

[merwok]

Is this rework needed? The original problem came from installing a new module and trying to import it in the same process without invalidating importlib caches

[henryiii]

Colab users don't know they need to invalidate importlib caches, and the help in colab doesn't tell them they need to. And invalidating the import caches doesn't work, since the problem is the .pth file is run at startup, and is not related to import caches. Remember, the problem can be seen with:

!pip install python-multipart==0.0.13
import multipart

The .pth files are run when the notebook kernel starts, which doesn't have any dependencies at all (Colab doesn't give you a way to pre-install deps). Then you install the package (which adds the .pth file), but it never gets a chance to run. Adding an importlib.invalidate_caches() in-between has no effect.

FWIW, this works, because it does exactly what the .pth file would have done:

!pip install python-multipart==0.0.13
import _python_multipart_loader
import multipart

But no one would know to do that.

[henryiii]

If you restart the session, Colab does keep the environment so it works the second time. Also, this works:

!pip install python-multipart==0.0.13
import site
site.main()
import multipart

But again, no one would know they need to do that.

[Kludex]

Thanks. Let's try this.

[witt3rd]

I am using rye (uv) and not pip and now FastAPI is broken since it can't import multipart.

[Kludex]

Yeah... I also can't import... 🤔

[defnull]

The build artefacts uploaded to pypi do not contain the second package for some reason. Installing directly from git also does not work, but installing from git+https://github.com/henryiii/python-multipart.git@henryiii/fix/importer does in fact still work. What!?

[Kludex]

I'm yanking python-multipart 0.0.14 and Starlette 0.41.1.

[defnull]

Ahh, found the issue. Installing from source (via pip install git+https://github.com/Kludex/python-multipart.git) does in fact work, but the source and wheel distribution files uploaded to pypi are incomplete. They are missing the /multipart/* files, and that's because in pyproject.toml the [tool.hatch.build.targets.sdist] section is still from the previous attempt. Wheels are built from the source distribution, so missing files in the sdist file are also missing in the wheel.

[henryiii]

Ah, forgot to rerun check-sdist. Sorry, will fix!