On Thu, 2019-11-21 at 13:26 -0500, Mohammed Naser wrote:
On Thu, Nov 21, 2019 at 1:20 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2019-11-21 17:54:32 +0000 (+0000), Stephen Finucane wrote: [...]
Unfortunately, flake8 3.x is a total rewrite and I haven't found a way to port things across.
[...]
I'm flat out of ideas on that so someone other than me is going to have to take this migration upon themselves or we're going to have to drop hacking so we can use a new flake8.
[...]
Oof, yes I guess it's high time to discuss this (sorry if there was a prior ML thread about it which I missed). So I guess the options I can see are:
A. keep running woefully outdated flake8 and friends (isn't working)
B. overhaul hacking to work as a file-level analyzer plug-in
C. improve flake8 to support string-level analyzer plug-ins
D. separate hacking back out so it's no longer a flake8 plug-in
E. stop running hacking entirely and rely on other flake8 plug-ins
While I don't have all the context to the work required, that does seem like that's the best option long term IMHO. i would prefer E as well. if we do need something like a hacking test that enforces no alias of privsep function for example the a plugin could be written for that 1 thing but in general i think we would be better off adopting exsitsing plugins our just using flake8 directly without plugins. i know we have some duplicate work checkers and other custom hacking test but i dont know if i have ever been hit by a hacking failure. i have pep8 issues all the time but never checks added by hacking.
Anything else? For sake of simplicity I'd favor option E. In our present reality where most folks already have far too much work on their respective plates, having one less project to maintain makes some measure of sense. Does hacking currently save teams more than enough effort to balance out the amount of effort involved in keeping it working with newer software? -- Jeremy Stanley