<p dir="ltr">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. </p>
<p dir="ltr">Rob</p>
<div class="gmail_quote">On 24 Jun 2015 10:21 pm, "Sean Dague" <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 06/23/2015 07:31 PM, Robert Collins wrote:<br>
> You may have seen your requirements update proposals start to include<br>
> things like:<br>
> MySQL-python;python_version=='2.7'<br>
><br>
> like in<br>
> <a href="https://review.openstack.org/#/c/194325/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/194325/</a><br>
> <a href="https://review.openstack.org/#/c/194325/3/test-requirements.txt" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/194325/3/test-requirements.txt</a><br>
><br>
> This is programmatic annotation of the Python versions that we need<br>
> these requirements for -- and the version(s) that we know works.<br>
><br>
> The syntax is PEP-426 environment markers:<br>
> <a href="https://www.python.org/dev/peps/pep-0426/#environment-markers" rel="noreferrer" target="_blank">https://www.python.org/dev/peps/pep-0426/#environment-markers</a><br>
><br>
> and we document it in pbr and openstack/requirements - this email is<br>
> just a heads for folk that aren't tracking those repositories.<br>
><br>
> To work with these, modern versions of pip (6 is the minimum) and<br>
> setuptools (I recommend the latest version always) and pbr (1.2.0) are<br>
> needed. Running with older versions is likely to fail - but these<br>
> tools are very backwards compatible.<br>
><br>
> The introduction of this is a necessary step to be able to calculate a<br>
> frozen set of requirements for each Python version we test on - if we<br>
> can't install all of global-requirements.txt on e.g. 2.7, then we<br>
> can't see what versions would be installed to calculate the delta for<br>
> the next upgrade. Calculating that frozen set of requirements is a<br>
> necessary condition to remove the variance of upstream releases from<br>
> impacting CI jobs and causing wedges.<br>
><br>
> We haven't (yet) introduced this machine readable data to stable/kilo,<br>
> but are likely to do so later this cycle, once we have the tooling in<br>
> place and locked in for constraints everywhere in master.<br>
><br>
> -Rob<br>
><br>
<br>
All of these proposals are now failing the requirements check jobs, so<br>
requirements updates are currently blocked.<br>
<br>
What's the resolution here?<br>
<br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>