[openstack-dev] [all]deprecating [test-]requirements-PYN.txt

Doug Hellmann doug at doughellmann.com
Mon Jun 29 11:56:16 UTC 2015


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



More information about the OpenStack-dev mailing list