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