[kinto0]

Summary:
Stack context: let uv check run Pyrefly (astral-sh/uv#22941): check PEP 723 scripts in their own uv environments, and check each selected workspace member as a project. Example workspace:

pyproject.toml             # root member `demo`; [tool.pyrefly] project-excludes = ["**/vendor"]
src/demo/main.py
scripts/tool.py            # PEP 723 script: dependencies = ["six"]
packages/a/m.py            # member `a`, no Pyrefly config
packages/a/vendor/m.py
packages/b/pyproject.toml  # member `b`, with its own [tool.pyrefly]
packages/b/m.py

• uv check --package demo runs pyrefly check --exclude-scripts --extend-project-excludes=packages/a --extend-project-excludes=packages/b --project-dir=.: it checks src/demo/main.py.

• uv check --package a runs pyrefly check --exclude-scripts --project-dir=packages/a: it checks packages/a/m.py, not packages/a/vendor/m.py.

• uv check --all-packages runs pyrefly check --exclude-scripts --project-dir=. --project-dir=packages/a --project-dir=packages/b: it checks each member with the config that governs it.

• uv check --script scripts/tool.py runs pyrefly check --script-command=<uv> --script-command=workspace ... --script-command=--script -- scripts/tool.py: it resolves six from the script's own environment.

• What: pyrefly check --project-dir <DIR> runs project mode for a directory. It finds the config from <DIR>, as pyrefly check does from the working directory, and checks the files that this config includes and that are under <DIR>. The flag repeats, so one run checks several projects. A file belongs to the deepest given directory that contains it, and is checked with the config of that directory.

• Why: uv check selects workspace members by their root directories. With pyrefly check <paths>, Pyrefly ignores the project-excludes of the config, so uv check and pyrefly check disagree. Path mode cannot apply the config excludes in a clear way when configs nest or when an exclude matches a path that the user names. Project mode already has one clear rule: one config selects the files and checks them. --project-dir keeps that rule and only limits it to a directory, so a member gets the same files and the same config as in pyrefly check.

• Why it works: most uv members have no [tool.pyrefly], so the config of a member is often the workspace root config. Each distinct config is walked once with its own includes and excludes, and a file is kept only by the config of the directory that it belongs to. The config finder gives each file under a directory that same config, and gives other files (dependencies) the config of the normal search.

Example: pyrefly check --project-dir=packages/a checks packages/a/m.py with the root config, so packages/a/vendor/m.py stays excluded. pyrefly check --project-dir=. --project-dir=packages/a --project-dir=packages/b (what uv check --all-packages runs) checks src/demo/main.py and packages/a/m.py with the root config, and packages/b/m.py with the config of packages/b. Before, uv ran pyrefly check packages/a, which also checked packages/a/vendor/m.py.

Differential Revision: D128428212

[meta-codesync]

@kinto0 has exported this pull request. If you are a Meta employee, you can view the originating Diff in D128428212.

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅