microsoft / microsoft/vscode-black-formatter

black is using cached pyproject.toml instead of the actual one

Open
#569 2 comments 1 reaction 0 assignees View on GitHub
bug good first issue help wanted needs PR
Dominant language
Python
Stars
196
Forks
49
Avg merge
1d 5h
Merged PRs (30d)
7

Description

## Diagnostic Data
- Python version: Python 3.11.9 (tags/v3.11.9:de54cf5, Apr 2 2024, 10:12:12) [MSC v.1938 64 bit (AMD64)] on win32
- Operating system (and version): Windows 11
- Version of tool extension you are using: 2025.2.0

py -m black --version
python -m black, 25.1.1.dev27+gd0ff3bd (compiled: no)
Python (CPython) 3.11.9

Black formatter extension settings:
- "fromEnvironment" option
- only additional arg is `--verbose`

## Behaviour

1. Create test.py, it's 93 symbols long.
```python
1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1
```
2. Setup .black in your home directory (e.g. C:\Users\xxx\ if you're on Windows).
```
[tool.black]
line-length = 120
```
3. Restart VS Code just to be sure.
4. Run "Format Document" on test.py. For more verbosity I've included `print('line length', line_length)` to `black/__init__.py`.
```
Using configuration from user-level config at 'L:\Users\xxxx\.black'.
line_length: 120
Found input source: "__BLACK_STDIN_FILENAME__l:\test\5_fifth_test.py"
l:\test\5_fifth_test.py already well formatted, good job.

All done! ✨ 🍰 ✨
1 file left unchanged.
```
5. Change line-length in .black to 90 and run "Format Document" again.
6. Output is exactly the same as above, line_length is still 120. So extension is ignoring updated .toml file.
7. Just to be sure that it's not a general `black` issue, let's run `black` from terminal. As expected, it's using the actual config, not the cached version.
```sh
cat L:\test\5_fifth_test.py | py -m black --verbose --stdin-filename l:\test\5_fifth_test.py -
line length 90
Identified `L:\test` as project root containing a .git directory.
Using configuration from user-level config at 'L:\test\config\.black'.
line_length: 90
Found input source: "__BLACK_STDIN_FILENAME__l:\test\5_fifth_test.py"
(
1
+ 1
+ 1
+ 1
+ 1
+ 1
+ 1
+ 1
+ 1
+ 1
+ 1
+ 1
+ 1
+ 1
+ 1
+ 1
+ 1
+ 1
+ 1
+ 1
+ 1
+ 1
+ 1
+ 1
)
reformatted l:\test\5_fifth_test.py

All done! ✨ 🍰 ✨
1 file reformatted.
```
8. Restarting Black formatter server helps.
```
Using configuration from user-level config at 'L:\Users\xxx\.black'.
line_length: 90
Found input source: "__BLACK_STDIN_FILENAME__l:\test\5_fifth_test.py"
reformatted l:\test\5_fifth_test.py

All done! ✨ 🍰 ✨
1 file reformatted.
```

### Expected Behavior

Extension to use the latest version of config to avoid confusion when config is edited during development and user is unsure whether the config was applied or not.

### Actual Behavior

Extension is using the cached version until server restart.

-----

Possibly related #519

No idea how exactly extension works, but I suspect it's running Python instance in background that's running `black` formatter with Python commands - noticed that extension output still had debug statements I've inserted into `black` for tests, though I've already removed them from the code.
And then maybe `black` is using `lru_cache` somewhere when it's parsing the config file and extension ends up also reusing the same config file because of it.

Contributor guide

Open the contributing guide

Research direction

Reproduce the behavior with VS Code's Format Document command, comparing it with `py -m black` and the output from `black/__init__.py`. Investigate the formatter server behavior and related issue #519, then verify that changing `.black` takes effect without restarting the server.

Written by the indexing model from the issue text.

Assessment

Tech stack
python, vscode
Domain
developer-experience, tooling
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.