-
Notifications
You must be signed in to change notification settings - Fork 30k
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
build,python: update flake8 rules #25614
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
We skip markdown and JS linting for the fixtures folder, I don't see why we should not do the same for python? |
This is not a style violation, this is an undefined name that has the potential to raise a NameError at runtime that would halt the script. Why would we want to miss the opportunity to flatten such a "showstopper" issue? E901,E999,F821,F822,F823 are the "showstopper" flake8 issues that can halt the runtime with a SyntaxError, NameError, etc. Most other flake8 issues are merely "style violations" -- useful for readability but they do not effect runtime safety.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should float patches in the test/fixtures/wpt
folder, that would just unnecessarily complicate the WPT update workflow (what happens the next time we update encoding tests?). Instead we should just ignore the fixtures folder for linting, that's also what we do for JS and markdown since we simply do not own those files and it does not worth the effort to maintain floated patches there.
What is upstream? We might not want to maintain these scripts but we do not want them to fail on our users. |
@joyeecheung web-platform-tests/wpt#14973 is merged in the upstream. Do we have a specific procedure to pull changes from wpt or this PR should be fine? |
Upstream means https://github.com/web-platform-tests/wpt - the files under
We do maintain a map of the commit sha for each subset, see the README of test/wpt: https://github.com/nodejs/node/tree/master/test/wpt#how-to-update-tests-for-a-module For But I still think we should just ignore |
As I see it, for CPP, markdown, and JS our linters are just for style, and we get actual code coverage with our test suite. For python we can lint for syntax and semantic issues. Also AFAIU we skip |
blocked by: #25639 |
36f30fc
to
7c7d86d
Compare
Rebased on master and latest WPT. Now this PR restores linting of |
@refack I am still -1 to lint |
Makes sense. I am okay with not linting Python scripts in test/fixtures.
As we don't control upstream, if they add code which fails our python linter, we have to update it. That adds to our maintenance. We don't have to do that, right? |
Is it best practice to be caught unaware when syntax errors come into our codebase? We might not control upstream but they certainly seem to react quickly when we alert them to issues in their code. My sense is that the vigilance demonstrated in web-platform-tests/wpt#14973 is a way for us to give back to those projects that we rely on. They help us and we should be willing to help them. |
@cclauss We always ignore |
* Tree-factor location of some *.py files for easy demarcation of areas to exclude. PR-URL: nodejs#25614 Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
PR-URL: nodejs#25614 Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
PR-URL: nodejs#25614 Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Landed in 914d6c9...1fc4255 |
Update tools/license-builder.sh in order to work normally after jinja2 and markupsafe were moved from tools/ to tools/inspector_protocol/ in an earlier commit. Refs: nodejs#25614 PR-URL: nodejs#27362 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Update tools/license-builder.sh in order to work normally after jinja2 and markupsafe were moved from tools/ to tools/inspector_protocol/ in an earlier commit. Refs: #25614 PR-URL: #27362 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com>
PR-URL: nodejs#25614 Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com> (cherry picked from commit a16a0fe)
xrange
does not exist in python3 hence it's lint blocking nodejs/build#1631, but it is not used in our codebase.As I see it we have 3 options to unblock:
node/Makefile
Lines 1294 to 1297 in f698386
Personally, I prefer option 1.
/CC @nodejs/testing @nodejs/python
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes