Re: [openstack-dev] [all][requirements] Whats with the python_version=='2.7' stuff thats showing up from today?
On 06/23/2015 07:31 PM, Robert Collins wrote: You may have seen your requirements update proposals start to include things like: MySQL-python;python_version=='2.7' like in https://review.openstack.org/#/c/194325/ https://review.openstack.org/#/c/194325/3/test-requirements.txt This is programmatic annotation of the Python versions that we need these requirements for -- and the version(s) that we know works. The syntax is PEP-426 environment markers: https://www.python.org/dev/peps/pep-0426/#environment-markers and we document it in pbr and openstack/requirements - this email is just a heads for folk that aren't tracking those repositories. To work with these, modern versions of pip (6 is the minimum) and setuptools (I recommend the latest version always) and pbr (1.2.0) are needed. Running with older versions is likely to fail - but these tools are very backwards compatible. The introduction of this is a necessary step to be able to calculate a frozen set of requirements for each Python version we test on - if we can't install all of global-requirements.txt on e.g. 2.7, then we can't see what versions would be installed to calculate the delta for the next upgrade. Calculating that frozen set of requirements is a necessary condition to remove the variance of upstream releases from impacting CI jobs and causing wedges. We haven't (yet) introduced this machine readable data to stable/kilo, but are likely to do so later this cycle, once we have the tooling in place and locked in for constraints everywhere in master. -Rob All of these proposals are now failing the requirements check jobs, so requirements updates are currently blocked. What's the resolution here? -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][requirements] Whats with the python_version=='2.7' stuff thats showing up from today?
The projects with the check job can't get updates to python specific requirements until the new longer is in place. I've nearly got that done, and its a critical priority for me since we don't want this stuff wedged. Projects can manually submit changes to non marker based requirements in the meantime, so it's not a total wedge. Rob On 24 Jun 2015 10:21 pm, Sean Dague s...@dague.net wrote: On 06/23/2015 07:31 PM, Robert Collins wrote: You may have seen your requirements update proposals start to include things like: MySQL-python;python_version=='2.7' like in https://review.openstack.org/#/c/194325/ https://review.openstack.org/#/c/194325/3/test-requirements.txt This is programmatic annotation of the Python versions that we need these requirements for -- and the version(s) that we know works. The syntax is PEP-426 environment markers: https://www.python.org/dev/peps/pep-0426/#environment-markers and we document it in pbr and openstack/requirements - this email is just a heads for folk that aren't tracking those repositories. To work with these, modern versions of pip (6 is the minimum) and setuptools (I recommend the latest version always) and pbr (1.2.0) are needed. Running with older versions is likely to fail - but these tools are very backwards compatible. The introduction of this is a necessary step to be able to calculate a frozen set of requirements for each Python version we test on - if we can't install all of global-requirements.txt on e.g. 2.7, then we can't see what versions would be installed to calculate the delta for the next upgrade. Calculating that frozen set of requirements is a necessary condition to remove the variance of upstream releases from impacting CI jobs and causing wedges. We haven't (yet) introduced this machine readable data to stable/kilo, but are likely to do so later this cycle, once we have the tooling in place and locked in for constraints everywhere in master. -Rob All of these proposals are now failing the requirements check jobs, so requirements updates are currently blocked. What's the resolution here? -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all][requirements] Whats with the python_version=='2.7' stuff thats showing up from today?
You may have seen your requirements update proposals start to include things like: MySQL-python;python_version=='2.7' like in https://review.openstack.org/#/c/194325/ https://review.openstack.org/#/c/194325/3/test-requirements.txt This is programmatic annotation of the Python versions that we need these requirements for -- and the version(s) that we know works. The syntax is PEP-426 environment markers: https://www.python.org/dev/peps/pep-0426/#environment-markers and we document it in pbr and openstack/requirements - this email is just a heads for folk that aren't tracking those repositories. To work with these, modern versions of pip (6 is the minimum) and setuptools (I recommend the latest version always) and pbr (1.2.0) are needed. Running with older versions is likely to fail - but these tools are very backwards compatible. The introduction of this is a necessary step to be able to calculate a frozen set of requirements for each Python version we test on - if we can't install all of global-requirements.txt on e.g. 2.7, then we can't see what versions would be installed to calculate the delta for the next upgrade. Calculating that frozen set of requirements is a necessary condition to remove the variance of upstream releases from impacting CI jobs and causing wedges. We haven't (yet) introduced this machine readable data to stable/kilo, but are likely to do so later this cycle, once we have the tooling in place and locked in for constraints everywhere in master. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
