Possible breakage against `beartype`?

[LecrisUT]

We recently got an issue reported on scikit-build-core that our editable install Finder is breaking tools like beartype that add sys.path_hooks ¹. The issue on our side seems to be that we should be running find_spec before trying to create our own spec ². Fwict mesonpy would have the same issue

meson-python/mesonpy/_editable.py

Line 255 in 47ea86f

def find_spec(fullname: str, tree: Node) -> Optional[importlib.machinery.ModuleSpec]:

Have you had similar issues reported? Or if it is not a problem for you, any guidance on what black magic is done here?

Footnotes

1. https://github.com/beartype/beartype/issues/556 ↩

2. https://github.com/scikit-build/scikit-build-core/pull/1493 ↩

[Glinte]

I took a look at meson-python with the help of GPT 5.6 and it seems like it have the same underlying issue. Here is a reproduction: https://github.com/Glinte/metapathology/tree/main/reproductions/meson-python-871-no-uv

---

AI written explanation that I touched up a bit:

With a meson-python editable install, MesonpyMetaFinder creates module specs directly using SourceFileLoader. This bypasses import
hooks registered through sys.path_hooks, such as beartype.claw.

A minimal reproduction imports an annotated submodule after enabling beartype_this_package(). Passing a string to an int parameter
succeeds silently, although the same code would error in a regular installation.

Metapathology (a debug tool I made) confirms the sequence:

1. beartype.claw inserts its FileFinder path hook.
2. MesonpyMetaFinder subsequently claims the submodule.
3. The path hook is never consulted.

This likely also explains #646, where pytest assertion rewriting is skipped in editable installations.

scikit-build-core fixed it by resolving mapped source files cooperatively through PathFinder, while retaining its editable mapping as authoritative. A similar approach may work here.