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 <[email protected]> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
