Open Stack

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.
> 
> > 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
> 
>