Conversation
konstin
added
enhancement
Stubs packages are different in that their name ends with `-stubs`, their module is `<module name>-stubs` (with a dash, not the generally legal underscore) and their modules contain a `__init__.pyi` instead of an `__init__.py` (https://typing.python.org/en/latest/spec/distributing.html#stub-only-packages). We add support in the uv build backend by detecting the `-stubs` suffix.
konstin
force-pushed
the
konsti/stubs-in-the-build-backend
branch
from
e3f6368 to
99d21fa
Compare
AlexWaygood
left a comment
AlexWaygood
left a comment
There was a problem hiding this comment.
This LGTM as far as I can tell!
If you want to see how ty handles this in its module resolver, you can grep for uses of this struct in the crates/ty_python_semantic/src/module_resolver directory in the Ruff repo
Co-authored-by: Alex Waygood <[email protected]>
| Identifier::from_str(package_name.as_dist_info_name().as_ref())?.to_string() | ||
| // Infer stubs packages from package name alone. There are potential false positives if | ||
| // someone had a regular package with `-stubs`. | ||
| if let Some(stem) = package_name.to_string().strip_suffix("-stubs") { |
There was a problem hiding this comment.
If a false positive happens, is there a way for a user to override that and say, "no, this is not a stubs package"?
Conversely, is there a way for a package that doesn't end with -stubs to be treated as a stubs package?
From this PR, it looks like the answer to both above is "no." Are we sure that's okay?
There was a problem hiding this comment.
In one direction, https://typing.python.org/en/latest/spec/distributing.html#stub-only-packages is a clear MUST about the -stubs suffix. In the other direction, I think I'd try this out, and if there are really packages with let's say foo_stubs we can add an override (tool.uv.build-backend.stubs = False). If we can have one option less by having this inference I'd prefer that.
Another option would be to require stubs packages to always declare a module name, so we can tell -stubs (stubs package) from _stubs (regular module).
There was a problem hiding this comment.
In one direction, https://typing.python.org/en/latest/spec/distributing.html#stub-only-packages is a clear MUST about the
-stubssuffix. In the other direction, I think I'd try this out, and if there are really packages with let's sayfoo_stubswe can add an override (tool.uv.build-backend.stubs = False). If we can have one option less by having this inference I'd prefer that.
I think that's good enough for me.
Another option would be to require stubs packages to always declare a module name, so we can tell
-stubs(stubs package) from_stubs(regular module).
I do like this idea! But I agree that inference probably makes more sense, and if necessary, we can add a way to override it if it comes up.
There was a problem hiding this comment.
I realized that we actually do have overrides: Setting the module name to _stubs vs. -stubs will trigger regular package vs. stubs package behavior.
There was a problem hiding this comment.
Nice. Yeah I think that SGTM!
|
Added some docs, mainly to make searching for "stubs" show that we support them. |
3 participants
Stubs packages are different in that their name ends with
-stubs, their module is<module name>-stubs(with a dash, not the generally legal underscore) and their modules contain a__init__.pyiinstead of an__init__.py(https://typing.python.org/en/latest/spec/distributing.html#stub-only-packages).We add support in the uv build backend by detecting the
-stubssuffix.Fixes #13546