Repository navigation
ruff analyze graph | head -n 10 panics #13442
Description
Activity
That's probably due to a println usage. We should use writeln instead and propagate the error when the pipe breaks
Just a suggestion to not propagate pipe "errors", as this is not really an error in the normal sense
https://www.pixelbeat.org/programming/sigpipe_handling.htmlI got it.
This is how ripgrep handles pipe errors: https://github.com/BurntSushi/ripgrep/blob/bf63fe8f258afc09bae6caa48f0ae35eaf115005/crates/core/main.rs#L55-L61
There are other approaches, but this is my favorite because:
- It doesn't require any platform specific APIs.
- It doesn't require inspecting or dealing with errors specially every time
writeln!is called. You just propagate it like normal and only treat it differently at the top-level of the program in one place. - It matches the expected behavior: a pipe error should make the program stop working and exit gracefully.
But yes, basically any
println!automatically introduces a potential bug of this variety.- added a commit that references this issue
on Sep 23, 2024 - added a commit that references this issue
on Sep 23, 2024 - added 2 commits that reference this issue
on May 1, 2026
It seems like
ruff analyze graphis sometimes unhappy when its output isn't fully consumed.Tested with ruffs 0.6.6 and 0.6.7:
A full example to reproduce, starting in an otherwise empty directory, would be:
git clone https://github.com/Eomys/pyleecan.git --depth=1 uv init uv add ruff==0.6.7 uv run ruff analyze graph | head -n 10edit: above is running on MacOS 14.6.1 . Although
headis the GNU version from homebrew's coreutils