I have found a solution that appears to work regarding getting stubtest running with editable install, though not sure its actually a good solution...

If you add the $REPO_ROOT/lib to the mesonpy-generated matplotlib-editable.pth file in site-packages, stubtest is able to run and give accurate results. (One slight change from setuptools editable install is that we had unused allowlist entries for untyped subpackages, but that is pretty trivial)

As far as I can tell it does not affect the special handling set up by mesonpy in _matplotlib_editable_loader, but does allow mypy to connect the stubs to the runtime.

All that said, while it may be good enough for a controlled CI environment, I don't like that as a solution for developers who may wish to run stubtest on their machine (note that mypy alone will work fine, just not with -p or -m, you must give it the lib/matplotlib path... stubtest requires runtime, so is more restricted) In my testing my editor integration still worked fine without any changes.

Perhaps this is a safe enough change and we should lobby/PR upstream to include it to support the mypy usecase.

The other option which seems to also be broken right now, but I don't think should be a problem, is to do a non-editable install... this is not great for the developer machine use case either, but at least does not involve editing generated files...

Currently I'm getting:

error: matplotlib failed to import, InvalidVersion: Invalid version: '"3.9.0.dev0"'

Which is a weird error on a couple fronts, firstly being why is version needed for importing in the first place?, secondly being why is that an invalid version?

Investigation has revealed that stubtest is doing (the __import__ equivalent of) from matplotlib import *, and that is what is triggering the "InvalidVersion". Testing on a REPL confirms that while import matplotlib is fine, trying to get __version_info__ (including a * import) breaks. The problem appears to be that there are quotes on __version__.

In summary:

• I think after sorting out __version_info__ problems probably the best short term path for CI is to use non-editable install for the stubtest job
• If that doesn't work, editing the pth file should
• May be worth talking to upstream about this usecase and seeing if the addition to the pth file can be included there, which would help for developer machines without having to edit a generated file.