Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

operate on files with certain hashbang #2192

Closed
spaceone opened this issue Jan 26, 2023 · 15 comments · Fixed by #3914
Closed

operate on files with certain hashbang #2192

spaceone opened this issue Jan 26, 2023 · 15 comments · Fixed by #3914
Labels
cli Related to the command-line interface

Comments

@spaceone
Copy link
Contributor

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

@charliermarsh charliermarsh added the cli Related to the command-line interface label Jan 26, 2023
@sciyoshi
Copy link
Contributor

Rather than looking for a specific shebang, maybe a configuration could be added to include certain files based on paths?

@charliermarsh
Copy link
Member

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.

@spaceone
Copy link
Contributor Author

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.

@charliermarsh
Copy link
Member

charliermarsh commented Jan 26, 2023

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?)

@spaceone
Copy link
Contributor Author

I guess they all have no extension. simple scripts.

@charliermarsh
Copy link
Member

We could consider checking non-extension files for hashbangs.

@spaceone
Copy link
Contributor Author

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)

@sciyoshi
Copy link
Contributor

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

@spaceone
Copy link
Contributor Author

yes, this is kind of my current workaround.

@spaceone
Copy link
Contributor Author

This workaround would also be needed in a pre-commit hook, where I did not yet find out how to achieve it.

@spaceone
Copy link
Contributor Author

spaceone commented Feb 8, 2023

ok, pre-commit already supports it: it first searches for files with .py[i] extension and then for executable files with common python hashbangs.

@charliermarsh
Copy link
Member

This could also be solved by #3410, sort of, though you'd have to enumerate them explicitly.

@neingeist
Copy link

neingeist commented Mar 8, 2023

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.)

@spaceone
Copy link
Contributor Author

hm, #3914 closed it but this allows only files with a specific extension. our files/scripts don't have any file extension.

@charliermarsh
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cli Related to the command-line interface
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants