Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 34.4k
build,python: update flake8 rules#25614
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
Uh oh!
There was an error while loading. Please reload this page.
Conversation
refack commented Jan 21, 2019 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
nodejs-github-bot commented Jan 21, 2019
cclauss left a comment
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
joyeecheung commented Jan 21, 2019
We skip markdown and JS linting for the fixtures folder, I don't see why we should not do the same for python? |
cclauss commented Jan 21, 2019 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
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.
|
joyeecheung left a comment • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
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.
cclauss commented Jan 21, 2019 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
What is upstream? We might not want to maintain these scripts but we do not want them to fail on our users. |
thefourtheye commented Jan 22, 2019
@joyeecheungweb-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? |
joyeecheung commented Jan 22, 2019 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
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 |
refack commented Jan 22, 2019
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 |
refack commented Jan 22, 2019
blocked by: #25639 |
refack commented Jan 22, 2019
Rebased on master and latest WPT. Now this PR restores linting of |
joyeecheung commented Jan 22, 2019
@refack I am still -1 to lint |
thefourtheye commented Jan 23, 2019
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? |
cclauss commented Jan 23, 2019
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. |
joyeecheung commented Jan 23, 2019 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
@cclauss We always ignore |
nodejs-github-bot commented Apr 13, 2019
Uh oh!
There was an error while loading. Please reload this page.
nodejs-github-bot commented Apr 13, 2019
nodejs-github-bot commented Apr 13, 2019
* Tree-factor location of some *.py files for easy demarcation of areas to exclude. PR-URL: nodejs#25614 Reviewed-By: Sakthipriyan Vairamani <[email protected]>
PR-URL: nodejs#25614 Reviewed-By: Sakthipriyan Vairamani <[email protected]>
PR-URL: nodejs#25614 Reviewed-By: Sakthipriyan Vairamani <[email protected]>
refack commented Apr 14, 2019
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 <[email protected]> Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Richard Lau <[email protected]>
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 <[email protected]> Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Richard Lau <[email protected]>
PR-URL: nodejs#25614 Reviewed-By: Sakthipriyan Vairamani <[email protected]> (cherry picked from commit a16a0fe)
xrangedoes 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