[lists.openstack.org代发]Re: [dev] Upgrading flake8 to support f-strings

Stephen Finucane sfinucan at redhat.com
Fri Nov 22 13:28:51 UTC 2019


On Fri, 2019-11-22 at 06:58 +0000, Brin Zhang(张百林) wrote:
> > 主题: [lists.openstack.org代发]Re: [dev] Upgrading flake8 to support
> f-strings
> > On Thu, 2019-11-21 at 13:26 -0500, Mohammed Naser wrote:
> > > On Thu, Nov 21, 2019 at 1:20 PM Jeremy Stanley <fungi at 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.
> 
> 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




More information about the openstack-discuss mailing list