Black should never try to format symlinks

[JelleZijlstra]

After upgrading to 23.9.1, due to #3846 I ran into the following situation:

• a/file.py is a symlink to b/file.py
• b/file.py is not formatted because it's in exclude

Previously, Black ignored the file. Now it wants to format it.

I would expect Black to not format these files. The actual files are excluded, the symlinks aren't themselves Python files. I think this can be implemented with a simple rule: never follow symlinks. If the file is in a place that Black should format, we'll find it through its resolved path. If it's not, we shouldn't format it.

cc @hauntsaninja

[hauntsaninja]

I don't have a use case, so I don't feel strongly. One of the reports about the old behaviour mentioned being happy if Black didn't format symlinks. Also not handling symlinks would make full cache runs of black faster (a la #3751).

That said, I'd take the bet that people are depending on being able to format via symlink. In today's world, I think everyone has the ability to get the behaviour they want, but we would have to think about whether we'd want a new flag if we made Black ignore symlinks.

Note another resolution to your issue is we could also make Black apply exclusion rules to both the symlink and the resolved file.

[embe-pw]

Another interesting case, that started ocurring due to #3846 and would also be fixed by ignoring symlinks:
Assume there is a symlink foo pointing to ignored-dir/bar.py (note that foo has no extension). black . will format foo (even though it does not have .py extension), effectively formatting ignored-dir/bar.py.

[morganwahl]

I have a use-case for black ignoring symlinks: we keep vendored dependencies in a directory called vendor, which we can then configure tools to ignore. However sometimes we need to reference the files inside the vendor dir from a different path, so we use symlinks. Black already ignores the vendor dir, but now it's trying to format files in it via the symlinks.