Open Stack

Jeremy Stanley wrote:
> [...]
> 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)

To be fair, option (A) *is* working, as long as you don't use f-strings. 
So we could just say that we should not use certain new language 
features. However, the error you get when you try using them is very 
confusing, and I expect more and more people to hit it as we move forward.

> 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
> 
> Anything else?

There is option (F) which is to explicitly add pyflakes>=1.4.0,<1.5 to 
projects that want to use f-strings (or to a new hacking version that 
projects will opt into). That will force flake8 to use pyflakes 1.4.0 
instead of 1.2.3, while still remaining compatible with hacking.

Looks like the only check 1.4.0 adds compared to 1.2.3 is duplicate 
dictionary keys[1], which hopefully should not trigger massive reports...

As an example, see this DNM change which adds a f-string in patchset 1, 
fails pep8 tests with the cryptic error, but passes them in patchset 2 
once pyflakes>=1.4.0,<1.5 is explicitly added in test-requirements:

https://review.opendev.org/695653

This obviously kicks the can down the road, but at least avoids getting 
it onto mriedem's lawn...

[1] 
https://github.com/PyCQA/pyflakes/commit/152ca182a603d7327925873db9a795797812968d

-- 
Thierry Carrez (ttx)