Flake8 fleshed out, and into CI
bskinn opened this issue · 7 comments
@jayvdb, I'll get this done as soon as I can. Might not be until later this week, though.
No worries.
Note you might want to consider using black instead. It is incompatible with flake8 and incompatible with isort, but lots of people love it.
I love black. The stdio-mgr codebase is already blackened; I run it regularly during development.
And, actually, as long as the max line lengths are set equal, I haven't really had a problem making flake8 and black play nice, with the exception of some ~uncommon scenarios in testing where I've needed to intermix imports and other statements at the top of a module. I can't remember whether I fixed those with # noqa or by refactoring. <shrug>
The flake8 setup I'm planning to apply here is the same one that's in place in another project of mine: see tox.ini and the flake8 plugins list. On one hand, it seems like a lot of plugins to be using -- on the other, though, each individual one makes sense to me to include, even though some of them necessitate a handful of # noqas.
If doing py2, you will want to add flake8-future-import to the list.
Some other you might consider at (now deprecated/unsupported) https://github.com/jayvdb/flake8-putty/blob/master/tox.ini
@jayvdb Based on the discussion at the other project (pytest-console-test?), I don't really want to mess with Python 2 at this point. I see the potential value to having even a single version out there with Py2 support... but with all of the [3]bytes/str // [2]str/unicode juggling, and all of the super() calls ... it just feels like it'd be a lot of work for something that's mostly in the rearview mirror at this point.
Ok, I'll leave that alone. I've also dropped the stdin raw buffer injection, at least temporarily, for similar reasons. While some people might need raw bytes, most wont, and it adds complexity and reduces the type checking which helps users navigate the bytes/unicode problem.
Or, well, I guess what it boils down to is: given the significant changes that are involved, I would rather keep master clean for Python 3.
I think I'd be ok with starting a python2 branch now, though, which would be Py2-specific; it'd disregard Python 3 compat entirely. It could then release into the v0.x space on PyPI -- I only have >=1 releases there, and all are tagged with python_requires>=3. So, a Python 2 user should only ever get the backport.