coherent.deps.pypi.NoDistributionForImport: _typeshed.StrPath

[jaraco]

Attempting to build the project emits:

coherent.deps.pypi.NoDistributionForImport: _typeshed.StrPath

[bswck-hai]

Yup, that was my change. I added a special import of a symbol from _typeshed typing-only stable API inside an if TYPE_CHECKING block.

[bswck-hai]

If that's a big issue for now, you could simply use str | os.PathLike[str] for now instead.

[bswck-hai]

Oh, sorry. Writing from my work account.

[jaraco]

Indeed, that root module doesn't show up in the database.

 🐚 http https://us-east-1.aws.data.mongodb-api.com/app/application-0-ponwfin/endpoint/distributions_for root==_typeshed
HTTP/1.1 200 OK
content-encoding: gzip
content-length: 28
content-type: application/json
date: Sat, 21 Sep 2024 19:21:58 GMT
server: mdbws
strict-transport-security: max-age=31536000; includeSubdomains;
vary: Origin
x-appservices-request-id: 66ef1cd5f0b732b4ec0cb426
x-frame-options: DENY
x-xgen-up-proto: HTTP/2

null

Who supplies _typeshed?

[bswck-hai]

Type checkers. Mypy and pyright see _typeshed in the typeshed because it comes bundled with them. Maybe we could somehow specialcase this, or defer as of now, anyway _typeshed is supplied by typeshed in https://github.com/python/typeshed, stdlib/.

[jaraco]

Perhaps if type_checking should be excluded when inferring the imports, but that's a feature not yet implemented. I'd like to handle that feature alongside environment-specific checks (e.g. if sys.version_info < or if plaform.system() == ), and include the TYPE_CHECKING dependencies in the type extra. For now, maybe coherent.deps should ignore that one as a special case.

[bswck]

Exactly. I think the same. 👍

[jaraco]

I added #11 to track the desired behavior, but now that I think about it, even if that feature were enabled, it wouldn't help with this issue, because even in the type-checking regime, that name doesn't resolve to a package. It will always need to be special-cased, as it's a magical name (not supplied by any wheel).

[bswck]

Yes. We can identify them as they occur in typeshed.

However, let's track if TYPE_CHECKING: blocks for any types-* (e.g. types-setuptools, those come from typeshed generally) and *-stubs (e.g. django-stubs) packages, if we can support them. _typeshed is indeed a special case. We could also special-case typing-extensions to not be installed at runtime if it is only in type-checking blocks (not sure how pyright would handle that one though).

[jaraco]

There are several places where I can filter out "excluded" or "magic" or "hidden" imports.

• Filter them out of coherent.deps.imports.get_module_imports
• Treat them as "standard" so they're treated like stdlib imports and excluded by coherent.build
• Exclude them inline in coherent.build when discovering imports
• Expand the coherent.deps.imports.Import to have another property and then have coherent.build exclude imports of that type.

The last option is the most invasive, and requires making a new release of both packages, but it also feels like the most correct to me. The advantage of that approach is that other callers could potentially examine these imports and treat them differently (a lower level interface remains unfiltered) and the data models are symmetric (.standard and .hidden have similar semantics).

[jaraco]

I wonder if any top-level name that begins with an underscore should be considered private and excluded. I'm leaning no. Even if a user were to import _pytest, coherent.deps should resolve that import to the pytest package.