[dev] Upgrading flake8 to support f-strings
Hi everyone, TL;DR: is it time for us to update flake8 and break the world? Long version: Ussuri-supported Python runtimes will be python 3.6 and 3.7, which opens the marvelous world of f-strings to us. For those not familiar with f-strings, I recommend reading: https://realpython.com/python-f-strings/ In a recent project[1] I tried to use them, only to get pep8 job failures[2]. The old flake8 version we are using in hacking is exploding trying to parse f-strings, with a cryptic "AttributeError: 'FlakesChecker' object has no attribute 'JOINEDSTR'" error. Of course that was long-fixed in pyflakes (>=1.4.0) but that version is only used starting in flake8>=3.3.0, and hacking is capping flake8<2.7.0. We do cap those aggressively for a reason: bumping that cap triggers pep8 job failures everywhere as flake8 decides to pay attention to slightly different things, and we lose a lot of time collectively chasing down those syntax glitches everywhere. Which is why we haven't really bumped those since 2016... But proper support of f-strings might be a good reason to update? Thoughts? [1] https://review.opendev.org/#/c/695457/1 [2] https://zuul.opendev.org/t/openstack/build/bd97e5397b184176aac94251cc0a9220 -- Thierry Carrez (ttx)
On 2019-11-21 18:13:02 +0100 (+0100), Thierry Carrez wrote: [...]
We do cap those aggressively for a reason: bumping that cap triggers pep8 job failures everywhere as flake8 decides to pay attention to slightly different things, and we lose a lot of time collectively chasing down those syntax glitches everywhere.
Which is why we haven't really bumped those since 2016... But proper support of f-strings might be a good reason to update? [...]
Well, the QA team used to increase the recommendation to the latest version of the various checkers in use at the start of every new development cycle. It's apparently been a few cycles now since anyone remembered to do it (or cared). -- Jeremy Stanley
On Thu, 2019-11-21 at 17:25 +0000, Jeremy Stanley wrote:
On 2019-11-21 18:13:02 +0100 (+0100), Thierry Carrez wrote: [...]
We do cap those aggressively for a reason: bumping that cap triggers pep8 job failures everywhere as flake8 decides to pay attention to slightly different things, and we lose a lot of time collectively chasing down those syntax glitches everywhere.
Which is why we haven't really bumped those since 2016... But proper support of f-strings might be a good reason to update? [...]
Well, the QA team used to increase the recommendation to the latest version of the various checkers in use at the start of every new development cycle. It's apparently been a few cycles now since anyone remembered to do it (or cared).
I remembered and tried to update hacking to use a new version of flake8 some time back [1]. Unfortunately, flake8 3.x is a total rewrite and I haven't found a way to port things across. I've tried at least a number of different approaches, all to no avail. I even went and asked the PyCQA folks for help [2] but unfortunately it looks like what we were doing isn't possible anymore. 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. Stephen [1] https://review.opendev.org/#/q/status:open+project:openstack/hacking+branch:... [2] https://gitlab.com/pycqa/flake8/issues/545
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 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
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.
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
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
主题: [lists.openstack.org代发]Re: [dev] Upgrading flake8 to support f-strings
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
On Thu, 2019-11-21 at 13:26 -0500, Mohammed Naser wrote: 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.
I also like E, but can we not update with flake8 every time, can we follow up with a stable version? In addition to the bug update, there will be a feature update, so is nova going to be updated? The maintenance of the plugin is also a big investment.
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
On Fri, 2019-11-22 at 06:58 +0000, Brin Zhang(张百林) 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
主题: [lists.openstack.org代发]Re: [dev] Upgrading flake8 to support f-strings On Thu, 2019-11-21 at 13:26 -0500, Mohammed Naser wrote: 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.
I also like E, but can we not update with flake8 every time, can we follow up with a stable version? In addition to the bug update, there will be a feature update, so is nova going to be updated? The maintenance of the plugin is also a big investment.
I might have misunderstood your question, but flake8 is one of the libraries that we don't manage via upper-constraints so projects are free to use whatever they want. nova will decide at some point to bump their flake8 version but no one else needs to do it in lockstep (or at all, if what they have works and they don't care to change it). Stephen
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
On 2019-11-22 06:58:28 +0000 (+0000), Brin Zhang(张百林) wrote: [...]
I also like E, but can we not update with flake8 every time, can we follow up with a stable version?
I don't understand, what's not stable? We managed to skip updating it for several cycles, and now we're talking about how to deal with the fact that we want to use newer Python constructs than the version of flake8 we've been stuck on for years. But really, we've said in the past that we should take the opportunity at the start of every development cycle (for Ussuri that's ~now) to globally increase the versions of static analysis tools we're relying on as a community and then freeze them for the remainder of the cycle. To me, that's as "stable" as makes sense.
In addition to the bug update, there will be a feature update, so is nova going to be updated? [...]
I don't know what you mean here either. Bug update where? Feature update where? Update Nova how? -- Jeremy Stanley
On 11/21/19 12:15 PM, Jeremy Stanley 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
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?
That would be unfortunate since I know some teams have extensive custom hacking rules to help out their reviewers[0]. That said, I'm not signing up to figure out how to make hacking work with modern flake8 and if the project is broken with no one to fix it then it's all academic. :-/ 0: https://github.com/openstack/nova/blob/master/nova/hacking/checks.py
On 2019-11-21 13:43:01 -0600 (-0600), Ben Nemec wrote: [...]
I know some teams have extensive custom hacking rules to help out their reviewers[0]. That said, I'm not signing up to figure out how to make hacking work with modern flake8 and if the project is broken with no one to fix it then it's all academic. :-/
0: https://github.com/openstack/nova/blob/master/nova/hacking/checks.py
Yeah, my line of thinking there was, "do the teams who rely heavily on hacking checks have the bandwidth to maintain the tool (or at least solve the current problem)?" -- Jeremy Stanley
On Thu, 2019-11-21 at 13:43 -0600, Ben Nemec wrote:
On 11/21/19 12:15 PM, Jeremy Stanley 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
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?
That would be unfortunate since I know some teams have extensive custom hacking rules to help out their reviewers[0]. That said, I'm not signing up to figure out how to make hacking work with modern flake8 and if the project is broken with no one to fix it then it's all academic. :-/
0: https://github.com/openstack/nova/blob/master/nova/hacking/checks.py
nova only has a couple but it might be intersting to convert those to precommit scripts. looking through them some of them do seam useful although other are just python 2 vs python 3 guidline that i hope will be less relevant now.
nova only has a couple but it might be intersting to convert those to precommit scripts. looking through them some of them do seam useful although other are just python 2 vs python 3 guidline that i hope will be less relevant now.
I would so very much love if we did NOT do that. Precommit hooks are super annoying for writing up quick PoCs and DNM patches, which we do a lot. --Dan
nova only has a couple but it might be intersting to convert those to precommit scripts. looking through them some of them do seam useful although other are just python 2 vs python 3 guidline that i hope will be less relevant now.
I would so very much love if we did NOT do that. Precommit hooks are super annoying for writing up quick PoCs and DNM patches, which we do a lot. ya true although i was referign to the precommit framework which we previously disucssed and said shoudl be optional to install. do you think we should keep/maintain hacking in nova and or port these to something else if not? anyway it was just a thought i dont want it to be mandaroy on every commit for the poc hacking reason either but it might be a way to keep the checks without having to contiue to
On Thu, 2019-11-21 at 15:32 -0800, Dan Smith wrote: maintain hacking.
--Dan
Keep in mind pre-commit tool != git-hooks, is like confusing JavaScript with Java ;) By default pre-commit does not install any hooks. Yes, you can install them, but in 9/10 cases I don't, I only have an alias pc="pre-commit run -a" which I run before each git-review. In fact I was considering adding an optional feature to git-review to auto run this when the repository has a .pre-commit-config.yml file. I am glad someone else opened the pre-commit subject before me. While it comes with its own challenges (git cloning), pre-commit resolves the problem of having predictable linter results by pinning them. Also it enables vey easy bumping of all of them. AFAIK, over the last year I removed hacking from several projects and replaced it with pre-commit and I am much happier. Not sure if others know but both bashate and doc8 can be used from pre-commit too. Extra bonus: we can avoid the case where we end-up having tons of jobs performing linting or style checks.
On 22 Nov 2019, at 13:11, Sean Mooney <smooney@redhat.com> wrote:
nova only has a couple but it might be intersting to convert those to precommit scripts. looking through them some of them do seam useful although other are just python 2 vs python 3 guidline that i hope will be less relevant now.
I would so very much love if we did NOT do that. Precommit hooks are super annoying for writing up quick PoCs and DNM patches, which we do a lot. ya true although i was referign to the precommit framework which we previously disucssed and said shoudl be optional to install. do you think we should keep/maintain hacking in nova and or port these to something else if not? anyway it was just a thought i dont want it to be mandaroy on every commit for the poc hacking reason either but it might be a way to keep the checks without having to contiue to
On Thu, 2019-11-21 at 15:32 -0800, Dan Smith wrote: maintain hacking.
--Dan
On 2019-11-22 13:51:10 +0000 (+0000), Sorin Sbarnea wrote: [...]
I am glad someone else opened the pre-commit subject before me. While it comes with its own challenges (git cloning), pre-commit resolves the problem of having predictable linter results by pinning them. Also it enables vey easy bumping of all of them. [...]
Is it still limited by only being able to install plugins from source, or can it consume released packages now?
Extra bonus: we can avoid the case where we end-up having tons of jobs performing linting or style checks.
Which can also be done by adding multiple check commands to a single tox testenv, or passing the names of multiple testenvs when invoking tox. Granted, tox is a fairly Python-oriented test tool, so pre-commit may be a more language-agnostic choice in that regard. -- Jeremy Stanley
On Fri, 2019-11-22 at 13:58 +0000, Jeremy Stanley wrote:
On 2019-11-22 13:51:10 +0000 (+0000), Sorin Sbarnea wrote: [...]
I am glad someone else opened the pre-commit subject before me. While it comes with its own challenges (git cloning), pre-commit resolves the problem of having predictable linter results by pinning them. Also it enables vey easy bumping of all of them.
[...]
Is it still limited by only being able to install plugins from source, or can it consume released packages now? i think that was a fundemetal design choice they made to only supprot git and not packages. the one thing i wish they would add support for is the ablity to define a set of global hooks in you home directory
e.g. ~/.config/.pre-commit.yaml so that you did not only have the choice of defining them in tree. or have the ablity to pass a file to use. if they supported either then we could use this ourselve without haveing to submit patches patches upstream. since we cant i have gone back to try spacemacs instead of using nano to see i can leverage the checkers built into that emacs distribution instead. i am likeing have a spell checker and auto indentation without having to go to a full idea like pycharm to get it. i love pycharm but i like codeing in a terminal too.
Extra bonus: we can avoid the case where we end-up having tons of jobs performing linting or style checks.
Which can also be done by adding multiple check commands to a single tox testenv, or passing the names of multiple testenvs when invoking tox. Granted, tox is a fairly Python-oriented test tool, so pre-commit may be a more language-agnostic choice in that regard.
yep but its a fair point. if the was ever added to the PTI i would expeact aht we would define a tox env from running all the pre-commit checks but i dont see that a major priority.
Keep in mind pre-commit tool != git-hooks, is like confusing JavaScript with Java ;)
By default pre-commit does not install any hooks. Yes, you can install them, but in 9/10 cases I don't, I only have an alias pc="pre-commit run -a" which I run before each git-review. In fact I was considering adding an optional feature to git-review to auto run this when the repository has a .pre-commit-config.yml file.
I am glad someone else opened the pre-commit subject before me. While it comes with its own challenges (git cloning), pre-commit resolves the problem of having predictable linter results by pinning them. Also it enables vey easy bumping of all of them.
AFAIK, over the last year I removed hacking from several projects and replaced it with pre-commit and I am much happier.
Not sure if others know but both bashate and doc8 can be used from pre-commit too.
Extra bonus: we can avoid the case where we end-up having tons of jobs performing linting or style checks. we need to keep the jobs even if we use pre-commit becasue it is optional to run it and we have to comply with teh PTI rules but addtional linters could be run via a singe pre-comite job.
On Fri, 2019-11-22 at 13:51 +0000, Sorin Sbarnea wrote: there is a patch to add precommit support to nova https://review.opendev.org/#/c/665518/ as an optional thing people can use if they choose too but that has been pending for 3 months at this point.
On 22 Nov 2019, at 13:11, Sean Mooney <smooney@redhat.com> wrote:
On Thu, 2019-11-21 at 15:32 -0800, Dan Smith wrote:
nova only has a couple but it might be intersting to convert those to precommit scripts. looking through them some of them do seam useful although other are just python 2 vs python 3 guidline that i hope will be less relevant now.
I would so very much love if we did NOT do that. Precommit hooks are super annoying for writing up quick PoCs and DNM patches, which we do a lot.
ya true although i was referign to the precommit framework which we previously disucssed and said shoudl be optional to install. do you think we should keep/maintain hacking in nova and or port these to something else if not? anyway it was just a thought i dont want it to be mandaroy on every commit for the poc hacking reason either but it might be a way to keep the checks without having to contiue to maintain hacking.
--Dan
On Thu, 2019-11-21 at 15:32 -0800, Dan Smith wrote:
nova only has a couple but it might be intersting to convert those to precommit scripts. looking through them some of them do seam useful although other are just python 2 vs python 3 guidline that i hope will be less relevant now.
I would so very much love if we did NOT do that. Precommit hooks are super annoying for writing up quick PoCs and DNM patches, which we do a lot.
$ git commit -n U iz wlcm.
--Dan
I would so very much love if we did NOT do that. Precommit hooks are super annoying for writing up quick PoCs and DNM patches, which we do a lot.
$ git commit -n
U iz wlcm.
Yeah, thanks, I'm aware. I said "super annoying" not "unworkaroundable". I stand by my characterization of them and don't think that they're a good way to enforce or even report on things like this. --Dan
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/152ca182a603d7327925873db9a79579781... -- Thierry Carrez (ttx)
participants (10)
-
Ben Nemec
-
Brin Zhang(张百林)
-
Dan Smith
-
Jeremy Stanley
-
Matt Riedemann
-
Mohammed Naser
-
Sean Mooney
-
Sorin Sbarnea
-
Stephen Finucane
-
Thierry Carrez