[openstack-dev] [ironic][infra][qa] Jobs failing; pep8 not found

Doug Hellmann doug at doughellmann.com
Fri Apr 20 13:27:37 UTC 2018


Excerpts from Jim Rollenhagen's message of 2018-04-20 09:05:23 -0400:
> On Fri, Apr 20, 2018 at 7:33 AM, Jim Rollenhagen <jim at jimrollenhagen.com>
> wrote:
> 
> > On Thu, Apr 19, 2018 at 3:21 PM, Doug Hellmann <doug at doughellmann.com>
> > wrote:
> >>
> >>
> >> Reading through that log more carefully, I see an early attempt to pin
> >> pycodestyle <= 2.3.1 [1], followed later by pycodestyle == 2.4.0 being
> >> pulled in as a dependency of flake8-import-order==0.12 when neutron's
> >> test-requirements.txt is installed [2]. Then later when ironic's
> >> test-requirements.txt is installed pycodestyle is downgraded to 2.3.1
> >> [3].
> >>
> >> Reproducing those install & downgrade steps, I see that pycodestyle
> >> 2.4.0 claims to own pep8.py but pycodestyle 2.3.1 does not [4]. So that
> >> explains why pep8 is not re-installed when pycodestyle is downgraded.
> >>
> >
> > Aha, interesting! That's a fun one. :)
> >
> > I think the real problem here is that we have linter dependencies listed
> >> in the test-requirements.txt files for our projects, and they are
> >> somehow being installed without the constraints.
> >
> >
> > This is because they're in the blacklist, right?
> >
> >
> >> I don't think they need
> >> to be installed for devstack at all, so one way to fix it would be to
> >> move those dependencies to the tox.ini section for running pep8, or to
> >> have devstack look at the blacklisted packages and skip installing them.
> >>
> >
> > Yeah, seems like either would work. With the latter, would devstack edit
> > these out of test-requirements.txt before installing, I presume? The former
> > seems less hacky, I'll proceed with that unless folks have objections.
> >
> 
> Although... this would need to be done in every project installed from
> source during the devstack run. I'm going to look into doing this in
> devstack instead to avoid spending all day moving patches.

In the short term we only need to fix the few projects with conflicting
requirements. In the longer term we could have a concerted effort to
move those dependencies. Someone creative might even be able to script
it, since we do have a list of the blacklisted items.

> 
> // jim



More information about the OpenStack-dev mailing list