<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 17, 2015 at 4:19 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On 02/16/2015 08:50 PM, Ian Cordasco wrote:<br>
> On 2/16/15, 16:08, "Sean Dague" <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br>
><br>
>> On 02/16/2015 02:08 PM, Doug Hellmann wrote:<br>
>>><br>
>>><br>
>>> On Mon, Feb 16, 2015, at 01:01 PM, Ian Cordasco wrote:<br>
>>>> Hey everyone,<br>
>>>><br>
>>>> The os-ansible-deployment team was working on updates to add support<br>
>>>> for<br>
>>>> the latest version of juno and noticed some interesting version<br>
>>>> specifiers<br>
>>>> introduced into global-requirements.txt in January. It introduced some<br>
>>>> version specifiers that seem a bit impossible like the one for requests<br>
>>>> [1]. There are others that equate presently to pinning the versions of<br>
>>>> the<br>
>>>> packages [2, 3, 4].<br>
>>>><br>
>>>> I understand fully and support the commit because of how it improves<br>
>>>> pretty much everyone’s quality of life (no fires to put out in the<br>
>>>> middle<br>
>>>> of the night on the weekend). I’m also aware that a lot of the<br>
>>>> downstream<br>
>>>> redistributors tend to work from global-requirements.txt when<br>
>>>> determining<br>
>>>> what to package/support.<br>
>>>><br>
>>>> It seems to me like there’s room to clean up some of these requirements<br>
>>>> to<br>
>>>> make them far more explicit and less misleading to the human eye (even<br>
>>>> though tooling like pip can easily parse/understand these).<br>
>>><br>
>>> I think that's the idea. These requirements were generated<br>
>>> automatically, and fixed issues that were holding back several projects.<br>
>>> Now we can apply updates to them by hand, to either move the lower<br>
>>> bounds down (as in the case Ihar pointed out with stevedore) or clean up<br>
>>> the range definitions. We should not raise the limits of any Oslo<br>
>>> libraries, and we should consider raising the limits of third-party<br>
>>> libraries very carefully.<br>
>>><br>
>>> We should make those changes on one library at a time, so we can see<br>
>>> what effect each change has on the other requirements.<br>
>>><br>
>>>><br>
>>>> I also understand that stable-maint may want to occasionally bump the<br>
>>>> caps<br>
>>>> to see if newer versions will not break everything, so what is the<br>
>>>> right<br>
>>>> way forward? What is the best way to both maintain a stable branch with<br>
>>>> known working dependencies while helping out those who do so much work<br>
>>>> for<br>
>>>> us (downstream and stable-maint) and not permanently pinning to certain<br>
>>>> working versions?<br>
>>><br>
>>> Managing the upper bounds is still under discussion. Sean pointed out<br>
>>> that we might want hard caps so that updates to stable branch were<br>
>>> explicit. I can see either side of that argument and am still on the<br>
>>> fence about the best approach.<br>
>><br>
>> History has shown that it's too much work keeping testing functioning<br>
>> for stable branches if we leave dependencies uncapped. If particular<br>
>> people are interested in bumping versions when releases happen, it's<br>
>> easy enough to do with a requirements proposed update. It will even run<br>
>> tests that in most cases will prove that it works.<br>
>><br>
>> It might even be possible for someone to build some automation that did<br>
>> that as stuff from pypi released so we could have the best of both<br>
>> worlds. But I think capping is definitely something we want as a<br>
>> project, and it reflects the way that most deployments will consume this<br>
>> code.<br>
>><br>
>>      -Sean<br>
>><br>
>> --<br>
>> Sean Dague<br>
>> <a href="http://dague.net" target="_blank">http://dague.net</a><br>
><br>
> Right. No one is arguing the very clear benefits of all of this.<br>
><br>
> I’m just wondering if for the example version identifiers that I gave in<br>
> my original message (and others that are very similar) if we want to make<br>
> the strings much simpler for people who tend to work from them (i.e.,<br>
> downstream re-distributors whose jobs are already difficult enough). I’ve<br>
> offered to help at least one of them in the past who maintains all of<br>
> their distro’s packages themselves, but they refused so I’d like to help<br>
> them anyway possible. Especially if any of them chime in as this being<br>
> something that would be helpful.<br>
<br>
</div></div>Ok, your links got kind of scrambled. Can you next time please inline<br>
the key relevant content in the email, because I think we all missed the<br>
original message intent as the key content was only in footnotes.<br>
<br>
>From my point of view, normalization patches would be fine.<br>
<br>
requests>=1.2.1,!=2.4.0,<=2.2.1<br>
<br>
Is actually an odd one, because that's still there because we're using<br>
Trusty level requests in the tests, and my ability to have devstack not<br>
install that has thus far failed.<br>
<br>
Things like:<br>
<br>
osprofiler>=0.3.0,<=0.3.0 # Apache-2.0<br>
<br>
Can clearly be normalized to osprofiler==0.3.0 if you want to propose<br>
the patch manually.<br></blockquote><div><br></div><div>global-requirements for stable branches serves two uses:</div><div><br></div><div>1. Specify the set of dependencies that we would like to test against</div><div>2.  A tool for<span style="font-size:13px"> </span><span style="font-size:13px">downstream </span><span style="font-size:13px">packagers to use when determining </span><span style="font-size:13px">what to package/support.</span></div><div><span style="font-size:13px"><br></span></div><div>For #1, Ideally we would like a set of all dependencies, including transitive, with explicit versions (very similar to the output of pip-freeze). But for #2 the standard requirement file with a range is preferred. Putting an upper bound on each dependency, instead of using a '==' was a compromise between the two use cases.</div><div><br></div><div>Going forward I propose we have a <a href="http://requirements.in">requirements.in</a> and a requirements.txt file. The <a href="http://requirements.in">requirements.in</a> file would contain the range of dependencies, and requirements.txt would contain the pinned set, and eventually the pinned set including transitive dependencies.</div><div><br></div><div>Thoughts?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class="im"><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
</span><div class=""><div class="h5">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>