ci/lint: add python linting

[nathanruiz]

Enabled the ruff python linter in CI, and resolved the issues that were detected by it. Ruff was used due to it's faster checking compared with other linters like pylint. This was added to resolve the python linting request in #13608.

[github-actions]

Download the artifacts for this pull request:

Windows

• mpv-i686-w64-mingw32
• mpv-x86_64-w64-mingw32
• mpv-x86_64-windows-msvc

macOS

• mpv-macos-12-intel
• mpv-macos-13-intel
• mpv-macos-14-arm

[kasper93]

Interesting. Not much changes overall. I think it is pretty tamed by default. Probably to make it useful, some more checks could be enabled. Not saying to be pedantic, but some minor things like mixed single and double string quotes, line length, some more common checks in python world, would probably be useful. We don't have much python code, so not really makes much difference either way, but might as well improve what we have.

[nathanruiz]

@kasper93 I've add a number of common checks that seem helpful:

• pyflakes and pycodestyle checks - this includes a number of standard python checks, including line too long
• pyflake8 standard, comma, and quotes - more standard checks, and checks for mixing of double and single quotes
• pep8-naming - pep8 naming convention checking
• pyupgrade - checking for code that could be written better with newer python features

[kasper93]

Looks quite complete now, thanks. There are remaining issues with scripts though, look up the CI result for them.

[llyyr]

Could this be adjusted to only run when a file with *.py is modified? Feels wasteful to run this everytime a PR is submitted

[nathanruiz]

@llyyr I looked into this briefly, but it seems like you can only exclude workflow execution based on files changed, not the jobs within. I'm happy to split it out into it's own workflow, but I wasn't sure if that is what you intended. I should also mention that the workflow took 7 seconds last time, so it may not have a huge impact.

[Akemi]

not sure about - Restrict line length to 88 character, since project wide we have a 80/100 limit. though i guess it's explicitly for c files?

your last commit ci/lint: fix macos dylib_unhell.py build issue should be part of ci/lint: replace format strings where the error was introduced. also this worries me that other small breakages were introduced because of the linting.

[edit]
if the commit messages don't describe what was actually done in those commits, or rather other things were changed with them, they are kinda pointless. also mixing actual code/procedural changes with styling changes are quite dangerous and really hard to spot in all those changes.

[kasper93]

not sure about - Restrict line length to 88 character, since project wide we have a 80/100 limit. though i guess it's explicitly for c files?

I agree on this point, we should use 100 limit in linters, while trying to keep it in 80 range, no point in forcing it if it looks worse.

[nathanruiz]

not sure about - Restrict line length to 88 character, since project wide we have a 80/100 limit. though i guess it's explicitly for c files?

I've updated the linter to only check for 100 characters per line.

[Akemi]

thanks for the changes and fixes. i quickly tested the macOS specific changes and the script still produce what is expected.

[kasper93]

I see no point to keep it in limbo, let's iterate on master if needed.