Fix and simplify check-python dev script #1934
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I revisited and simplified a few things in the
check-pythondev script, partially as follow-up of https://github.com/tiny-pilot/tinypilot-pro/pull/1714:ADDITIONAL_PY_SCRIPTS(which was outdated) for a dynamic lookup mechanism, which ensures to always catch all scripts inscripts/.check-for-init-python-filesinto thecheck-pythonscript. It seemed weird to me to have this script separately and everything else embedded."→')This structure also makes it a bit easier to include the front panel sources here: I realized that the
check-pythonscript also doesn’t sufficiently account for the front panel. So for the upstream merge, I plan to add these changes (see this Pro branch I used for testing):check-python. That actually triggers some missing ignore-directives (e.g., in.yapfignore), that also would show up when running locally.ruffdoesn’t cover the front panel, so we have to add it there.yapfalready covers the front panel.coveragedoesn’t include the front panel – we don’t have any tests in the front panel, but I also wasn’t able to figure out how to make it even look there…pylintdoesn’t include the front panel – unfortunately, I wasn’t able to make that happen trivially, so we should look into this separately – there are some minor style violations there.I think the aforementioned problems would profit from a revised project structure, where we properly share dev dependencies for both our Python services. The current nested structure doesn’t seem to lend itself as nicely for this.