Excerpts from Robert Collins's message of 2015-06-29 15:59:12 +1200: > Hi, so we're nearly ready to deprecate the python-version-specific > requirements files. Once we have infra's requirements cross checking > jobs all copacetic again, we should be able to move forward. > > There isn't a specific spec for this in pbr, and I wanted to get some > broad input into the manner of the deprecation. > > As a reminder, for context, we have several bits of context to consider. > > Firstly, we're aligning with upstream packaging precepts, so we want > to remove all non-deployment-specific usage of requirements.txt and > similar files. > > Secondly, the Python version specific files are incompatible with > universal wheels, which are desirable because our infrastructure only > knows how to build one wheel when a tag is made, and its less > redundant downloads for users with multiple python versions. > > Thirdly, we can't do any backwards incompatible changes in pbr without > breaking any existing users of $thing. Because we're a setup_requires, > and setuptools can't handle version dependencies of setup_requires. So > whatever we do will affect all stable branches immediately, in all > gate jobs. > > I think we should do three things: > - error if universal builds are requested and python versioned > requirements files are present.
That may break some of the Oslo stable libs, since not all of them were ready for Python 3 last cycle, and certainly not before. Have you done any analysis to find those libs so we can get patches ready preemptively? Doug > - warn on stdout if versioned requirements files are present > - start reflecting the 'test' extra into tests_require in the setup_kwargs > > The downside of this is that it will warn indefinitely for existing > stable branches. But I think that that is tolerable. If its not, we > could write a timestamp somewhere and only warn once/day, but I think > that that is likely to lead to confusion, not clarity. > > -Rob __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
