[ty] Add allowed-unresolved-imports setting#22800
Merged
AlexWaygood merged 13 commits intomainfrom Jan 26, 2026
Merged
Conversation
MichaReiser
added
configuration
MichaReiser
requested review from
Gankra,
dcreager and
sharkdp
as code owners
Typing conformance resultsNo changes detected ✅ |
|
MichaReiser
changed the title
allowed-unresolved-imports setting"allowed-unresolved-imports setting
Member
Author
|
There's one TODO, adding the same early-exit to ruff/crates/ty_python_semantic/src/types/infer/builder.rs Lines 8686 to 8695 in ceb876b but I haven't been able to come up with a test case, which is why I haven't done this yet. |
|
BurntSushi
approved these changes
Jan 22, 2026
| Supports glob patterns: | ||
| - `*` matches zero or more characters except `.` (e.g., `foo.*` matches `foo.bar` but not `foo.bar.baz`) | ||
| - `**` matches any number of module components (e.g., `foo.**` matches `foo`, `foo.bar`, etc.) | ||
| - Prefix a pattern with `!` to exclude matching modules |
Member
There was a problem hiding this comment.
This all looks reasonable to me. Is this also what mypy does?
Member
Author
There was a problem hiding this comment.
No, mypy doesn't distinguish between * and **.
A pattern of the form qualified_module_name matches only the named module, while dotted_module_name.* matches dotted_module_name and any submodules (so foo.bar.* would match all of foo.bar, foo.bar.baz, and foo.bar.baz.quux). source
I do think the distinction between ** and * is useful. I also don't think mypy supports test*, which seems useful to me as well.
Member
There was a problem hiding this comment.
Yeah I agree. Distinguishing between "match one component" and "match many" is nice.
Member
There was a problem hiding this comment.
Hmm, I'm not sure I agree with you two here! I can't see a use case for telling ty to ignore an unresolved foo.bar import but not to ignore an unresolved foo.bar.baz import. If foo.bar is unresolved, then foo.bar.baz will always be unresolved too -- that's just the nature of how imports work in Python! Distinguishing between "match one component" and "match many" might make sense in the abstract for glob patterns in general, but for this specific application it feels to me like it adds complexity for little purpose
Member
There was a problem hiding this comment.
I also think there's value in matching what mypy does; it'll be what users migrating from mypy will expect
Member
There was a problem hiding this comment.
Okay, I think I see the use case. You might want to use aws* to match, e.g., all modules that start with aws, but not necessarily their submodules.
I'll refine the docs here slightly to give some clearer examples of situations where it might be useful to use * instead of (or in combination with) **
| regex_set: RegexSet, | ||
| /// Parsed glob metadata. | ||
| globs: Box<[ModuleGlob]>, | ||
| } |
Member
There was a problem hiding this comment.
I'm glad you resisted the urge to copy globset's optimizations. I was going to suggest not bringing them in initially if you did. :P
Member
Author
There was a problem hiding this comment.
Haha, I was counting on RegexSet doing a good job at optimizing the most trivial literal cases for me.
Member
There was a problem hiding this comment.
It... probably will. The globset stuff was written before I overhauled the regex internals, so there are undoubtedly some things in globset that don't need to be there any more. But I'm not sure which! Hah.
| ModuleNameMatch::Exclude | ||
| } else { | ||
| ModuleNameMatch::Include | ||
| } |
AlexWaygood
reviewed
Jan 26, 2026
Comment on lines
+8861
to
+8869
| let settings = self.db().analysis_settings(self.file()); | ||
|
|
||
| if settings | ||
| .allowed_unresolved_imports | ||
| .matches(&full_submodule_name) | ||
| .is_include() | ||
| { | ||
| return; | ||
| } |
Member
There was a problem hiding this comment.
I don't love that we have to repeat this three times, but I'm not immediately sure what a more DRY solution would be
AlexWaygood
approved these changes
Jan 26, 2026
Member
AlexWaygood
left a comment
AlexWaygood
left a comment
There was a problem hiding this comment.
Thank you, this is great!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds a new
analysis.allowed-unresolved-importssetting that allows users to suppressunresolved-importerrors for modules matching a glob in theallowed-unresolved-importslist.The new setting mimics
src.includeby supporting module-name globs and negated glob patterns. Negated globs are useful when using this setting withoverrideswhere an import should not be ignored for a specific subfolder.Fixes astral-sh/ty#1354
Adding support for astral-sh/ty#2082 should be straightforward after this change, as all the infrastructure is in place.
While the globbing is heavily inspired by
GlobSet, I didn't go as far as optimizing the implementation for literals etc. It also doesn't support all glob meta characters, but these are both things we can address in the future.CC: @ntBre because I think we wanted something similar in Ruff.
Review
It probalby makes sense for @BurntSushi to review the
ModuleGlobSet"stuff" and for someone familiar with our import system to review theTypeInferenceBuilderchangesTest plan
Added mdtests and glob tests