Quick update: - Items *1* (flake8 upgrade) and *2* (removing sub .flake8 files) are now landed. - Item *3* (blacklist) should land in the next week or two. - Items *4-5* have no timeline yet.
On Fri, Feb 1, 2019 at 11:08 AM Andrew Halberstadt <a...@mozilla.com> wrote: > Hi everyone, > > Just wanted to let you know of a few upcoming changes to our > flake8 linter that I'm planning: > > *1. Upgrading flake8, pycodestyle and pyflakes* > > It's been awhile since we've bumped these tools. The upgrades > will be: > flake8: 3.5.0 -> 3.7.4 > pycodestyle: 2.3.1 -> 2.5.0 > pyflakes: 1.5.0 -> 2.1.0 > > These updates add the following new error codes: > F632, F633, F723, F811, E117, W504, W605, W606 > > For their meanings see: > http://flake8.pycqa.org/en/latest/user/error-codes.html > http://pep8.readthedocs.io/en/latest/intro.html#configuration > > I plan to disable these new rules at first. They'll be separated > via comment from the other intentionally disabled rules in the > config. > > > > *2. Deprecating subdirectory .flake8 files (bug 1515746 > <https://bugzilla.mozilla.org/show_bug.cgi?id=1515746>)* > > There will be a single canonical .flake8 file in the root of the > repository. The main motivation for this is an implementation > detail where this feature is preventing us from switching to a > blacklist. But this will also simplify our configs and code, keep > editor integrations in-line with |mach lint|, and improve perf. > > This is now possible because of flake8 3.7's new per-file-ignores > <http://flake8.pycqa.org/en/latest/user/options.html#cmdoption-flake8-per-file-ignores> > feature. This can be implemented without any change to how our > current files are linted, i.e no source code will be modified as part > of this change. > > > > *3. Switching to a blacklist (bug 1367092 > <https://bugzilla.mozilla.org/show_bug.cgi?id=1367092>)* > > Currently we register > <https://searchfox.org/mozilla-central/source/tools/lint/flake8.yml#4> > which files and directories should be linted. > This is not ideal because any new code added outside of those > directories will not be linted by default. Instead, we will define > which paths *shouldn't* be linted. This will be possible thanks to > the deprecation of subdirectory configs (it's a long story). > > As part of this process I intend to only exclude what is absolutely > necessary (within reason). This means some .py files which had > no issues but weren't being linted will start being linted. It also > means new modules will automatically be linted. > > > > *4. Enabling flake8-isort (bug 1492495 > <https://bugzilla.mozilla.org/show_bug.cgi?id=1492495>)* > > Isort is a tool to format python imports, and flake8-isort is a shim > to use it as a linter. I'm proposing flake8-isort over the more > popular flake8-import-order because we'll get automatic fixing for > free. Manually re-ordering imports is not something I think anyone > should be subjected to. > > Isort is configurable, but the default is pretty close to what we > unofficially tend to use anyway, namely: > > # stdlib imports > import os > import sys > from collections import OrderedDict, defaultdict > > # external dependency imports > import requests > from mozprocess import ProcessHandler > > # internal imports > import mymodule > from . import name > > I think I'd like to enable this at the 'warning' level to start (so it > doesn't cause backouts or show up without --warnings). This will > give people a feel for the new syntax and allow us to start using > --fix to re-order imports before making it a hard requirement. > > This item item is potentially controversial, so let me know if you > have any objections to enabling this. > > > *5. Mass enabling of rules* > > With flake8 + dependencies upgraded and flake8-isort installed, > we'll have many new rules (which were all turned off by default) to > triage and enable. Ideally this would all happen in a single massive > commit similar to our format efforts in other languages. We would > use the magic commit string to keep it out of git/hg blame. > > > Not everything will happen all at once, the items at the top of the > list will land before the items near the bottom. Let me know if you > have any questions or objections! > > Cheers, > Andrew >
_______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
