Repository navigation
pyrefly coverage should respect project-excludes from the config #3909
Description
NumPy's pyproject.toml
(src) looks like this:
[tool.pyrefly]
project-includes = ["numpy/**/*.pyi"]
project-excludes = ["numpy/typing/tests/**"]But pyrefly coverage check numpy (pyrefly==1.1.1) still reports symbols from numpy/typing/tests/**. They only disappear if I repeat the glob on the CLI with --project-excludes="numpy/typing/tests/**".
I know passing a path switches to single-file mode, where config project-includes/project-excludes are ignored (same as #1360, closed as by-design). But dropping the excludes is surprising for coverage: pointing it at a package while keeping the project's tests/** excludes seems like a pretty natural thing to want. I, at least, fully expected this to "just work", and had to spend a lot of time figuring out that it had to do with the numpy path I specified, and that using pyrefly coverage check (without the numpy path) will respect the configured project-excludes.
The docs justify this behavior by files resolving to different configs. But there's no ambiguity when there's a single config at the root, which I expect to be the most common scenario in practice.
So I propose that, in "single-file mode", the config's project-excludes still apply when all files resolve to the same config (still ignoring project-includes, since the path already narrows those).
Since this is broader than just pyrefly coverage, I'll wait to see what you think about this before I'll start working on a PR.
Activity
yangdanny97 commentedon Jun 23, 2026
If it's not too complex to implement I'm in favor
cc @connernilsen for second opinion
kinto0 commentedon Oct 30, 2026
The "when the same config applies to all FILES" part gets tricky: if certain files in a file-based check read one config and other files read the other config, the excludes can differ and which should we honor?
What you're really doing when running
pyrefly coverage check path/to/diris explicitly saying you want a folder checked, so it gets confusing if that folder is excluded in the config (0 errorsjust because nothing was checked is not a great scenario). Maybe we can have some heuristics that include the exact folder you tell it and exclude all others, but that gets tricky.What I might propose instead is a project-based check. After something like this, you can do
pyrefly coverage check --project-dir numpywhich will do a project-based check (meaning check the config) of the folder at numpy. It will automatically exclude sibling folders even if they're included in the project. How does that sound?Maybe this is what everyone means when they do a files-based check on a folder. Maybe we should automatically do that when you run
pyrefly check numpybut do a files-based check when you runpyrefly check numpy/.Thoughts?
jorenham commentedon Nov 2, 2026
Right now in #5447, if there are multiple configs for multiple files, then none of the excludes are honored, i.e. the current behavior. But I think that projects that use multiple configs are in the minority, and that it's even less common for such multi-config projects to check multiple files with different configs. So I expect that in practice this won't be a very likely situation.
I guess that'd simplify things implementation-wise, but I still think it could be confusing to users that
pyrefly check numpydoesn't respect the excludes. I bet that if you ask someone new to pyrefly whether they expectpyrefly coverage pkgto respect the excludes in their pyrefly config, that almost all of them well answer "yes". Only doing this when you pass--project-dirfeels more like a workaround than an actual solution to me.That might be a bit confusing to some. For example, see letmaik/rawpy#304 (comment). I can already picture a bug report titled "
pyrefly check pkgandpyrefly check pkg/give different results".