Cache causes confusing behavior when running with and without "--unstable"
Closed this issue · 1 comments
twitchard commented
Describe the bug
If you run black
without --unstable
on a file and then run it with --unstable
, it won't apply changes that should be applied by --unstable
.
To Reproduce
black --version
python_code='long_line = " 20 30 40 50 60 70 80 90 100 110 120 130 140"'
echo "$python_code" > my_file.py
echo "Formatting without --unstable..."
black -l 120 my_file.py
cat my_file.py
echo "Formatting with --unstable..."
black -l 120 --unstable my_file.py
cat my_file.py
echo "Adding a newline to invalidate the cache..."
echo -e "\n" >> my_file.py
echo "Formatting with --unstable again..."
black -l 120 --unstable my_file.py
cat my_file.py
for me outputs
black, 24.8.0 (compiled: yes)
Python (CPython) 3.12.4
Formatting without --unstable...
All done! ✨ 🍰 ✨
1 file left unchanged.
long_line = " 20 30 40 50 60 70 80 90 100 110 120 130 140"
Formatting with --unstable...
All done! ✨ 🍰 ✨
1 file left unchanged.
long_line = " 20 30 40 50 60 70 80 90 100 110 120 130 140"
Adding a newline to invalidate the cache...
Formatting with --unstable again...
reformatted my_file.py
All done! ✨ 🍰 ✨
1 file reformatted.
long_line = (
" 20 30 40 50 60 70 80 90 100 110 120 "
" 130 140"
)
Expected behavior
- Adding
--unstable
to the command should cause black to ignore cache results that were produced without--unstable
. - To me "1 file left unchanged" misleadingly suggests that
black
looked at the file and determined there were no changes to make. A wording like "1 unchanged file ignored" would have helped me understand a cache was in play. - Similarly the fact that
black --help
makes no mention of a cache / has no flag to bypass was a barrier to me understanding that this was a possibility.
Environment
- Black's version: 24.8.0
- OS and Python version: 3.12.4, Mac OS
JelleZijlstra commented
Thanks, we were missing --unstable
in the cache key. Submitted a fix in #4466.