Open Stack

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.
 - 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
-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud