Trying to read from stdin dumps no content when stdin-filename is excluded

[sacereda]

When working in a project where some paths are not blacked yet, you may configure file discovery and run something like:

black .

Once you have this, you may need to integrate black in your editor, and some plugins end up piping from stdin:

stdin | black - --stdin-filename "$FILEPATH"

The problem is the integration will fail when trying to format a file being excluded by force-exclude directive.

You can check other tools like ruff output unformatted stdin in this case:

astral-sh/ruff#8596

So they can have editor integrations such as:

https://github.com/JoshHayes/emacs-ruff-format/blob/main/ruff-format.el#L43

Where they just pipe the content of the buffer to their cli

[MeGaGiGaGon]

Yay, conflicting requirements. I previously made this exact behavior not happen in #4539 , fixing #4232 , because they wanted the opposite thing for their tooling, where reading from stdin with a force excluded path wouldn't give an output. Feel free to read the issue and PR, maybe I misinterpreted what they actually wanted. Past that I don't really have an opinion/preference on which of these behaviors would be better, and I also don't know what to do in these conflict of needs situations.
Edit: On a bit further thought, this isn't exactly the same, because under the old behavior stdin would be formatted, while under your proposed changes it wouldn't be formatted, just returned. I guess that would be fine? Still not sure, since I've never used integrations for this sort of thing.

[tusharsadhwani]

I don't think there's a conflict, i think they just didn't want formatting to happen. Outputting the original source back to stdout should be okay if I'm reading this correctly.

[tusharsadhwani]

FWIW i do think that if we're exiting with zero we should be outputting something, rather than nothing.

[sacereda]

Yay, conflicting requirements. I previously made this exact behavior not happen in #4539 , fixing #4232 , because they wanted the opposite thing for their tooling, where reading from stdin with a force excluded path wouldn't give an output. Feel free to read the issue and PR, maybe I misinterpreted what they actually wanted. Past that I don't really have an opinion/preference on which of these behaviors would be better, and I also don't know what to do in these conflict of needs situations. Edit: On a bit further thought, this isn't exactly the same, because under the old behavior stdin would be formatted, while under your proposed changes it wouldn't be formatted, just returned. I guess that would be fine? Still not sure, since I've never used integrations for this sort of thing.

Your original change it's ok, stdin should be excluded if stdin_filename matches any exclusion.

I think when you run the cli with a path it's ok to not modify the file if it's excluded, but when you run it through a pipe, say:

cat no_format.py | black - --stdin-filename no_format.py

you would expect to output the original content. At least that's what's intended in #4610.

That's how other formatters such as ruff or clang-format work:

>cat noformat.c

int main(       ) {
        return 0;
}

>cat .clang-format | grep DisableFormat
DisableFormat:   true

>cat noformat.c | clang-format --assume-filename=noformat.c

int main(       ) {
        return 0;
}