astral-sh
operate on files with certain hashbang
ruff seems only to search for files with .py (maybe also `.pyi) file extensions?!
it would be good to detect some certain hashbangs like:
!#/usr/bin/python
!#/usr/bin/python3
!#/usr/bin/python -b
!#/usr/bin/env python3
and it would be nice to be able to put further definitions in the config files, we e.g. have definitions like:
#!/usr/share/test/runner python3
#!/usr/share/test/runner py.test-3
Rather than looking for a specific shebang, maybe a configuration could be added to include certain files based on paths?
Yeah, I'm extremely hesitant to check every file for a shebang.
If you pass a file to Ruff directly, it will check it, even if it's not a .py or .pyi file (like ruff /path/to/file). That's what most users have done in the past. Though I'd be open to some kind of opt-in list.
I wouldn't use a configurable list of files as files are too often just changing by too many people. The files are tracked in git and all of them might be relevant.
What's wrong with checking hashbangs? I am using it currently and it is not really making a performance issue.
I assume it will come at a performance cost. I'd need to benchmark it.
Is there a common extension on those files? (Or even: do they all have no extension?)
That would be great. we have 462 python files without file extensions and 4 python files with (accidental) file extensions (.in, .conf, .3, .0-dev)
Another simple workaround would be to find the files separately and pass those explicitly to ruff, e.g. (with ripgrep):
rg -l -0 '\A#!/usr/bin/env python' | xargs -0 ruff
This workaround would also be needed in a pre-commit hook, where I did not yet find out how to achieve it.
ok, pre-commit already supports it: it first searches for files with .py[i] extension and then for executable files with common python hashbangs.
This could also be solved by https://github.com/charliermarsh/ruff/issues/3410, sort of, though you'd have to enumerate them explicitly.
This could also be solved by #3410, sort of, though you'd have to enumerate them explicitly.
For me, it would suffice to include them explicitly and I agree that performance could suffer if ruff would read every file to search for the bang.
(Using the term "include" here, because the include option is how you can do it with Black.)
hm, #3914 closed it but this allows only files with a specific extension. our files/scripts don't have any file extension.
Ah yeah, the reasoning was that this now provides a manual workaround, analogous to Black's own configuration (whereby you can specify the script names in the extend-include vector). I'm open to re-opening this, although I don't yet have a solution that I'm happy with for supporting arbitrary scripts via shebangs, so I can't commit to improving it further.