#20589 black reformatting can ignore configuration in nested directory, depending on sandbox contents Issue created by huonw Describe the bug If a repo has configuration for black in a

pyproject.toml

in a nested directory (e.g.

a/

), the formatting implied by that config may or may not be applied to files within

a/

, depending on how Pants decides to layout the sandbox for each process invocation: • if it only includes files in

a/

, the configuration applies • if it includes files outside of

a/

, the configuration doesn't apply Reproducer:

cd $(mktemp -d)

cat > pants.toml <<EOF
[GLOBAL]
pants_version = "2.19.0"

backend_packages = [
  "pants.backend.python",
  "pants.backend.python.lint.black",
]

[python]
interpreter_constraints = ["==3.*"]
EOF

mkdir -p a b

cat > a/pyproject.toml <<EOF
[tool.black]
line-length = 10
EOF

echo 'python_sources()' > a/BUILD

echo '123456789 + over_ten' > a/reformat.py

# OK: error that a/reformat.py would be changed
pants lint ::

echo 'python_sources()' > b/BUILD
echo '123456789 + over_ten' > b/no_format.py

# BUG: no error, a/reformat.py is "okay"
pants lint ::

The first

lint

would make changes, because

a/reformat.py

is the only file that exists, and thus is definitely in a sandbox by itself, next to

a/pyproject.toml

. ✅ The second lint, on the exact same

a/reformat.py

doesn't make changes, because it now includes

b/no_format.py

in the sandbox, and thus the configuration doesn't apply. ❌ Pants version 2.19.0 OS macOS Additional info This is essentially a black-focused version of #17739, being concrete about the impact it has on the use of black. pantsbuild/pants