Open Stack

On 2/17/15, 16:27, "Joshua Harlow" <harlowja at outlook.com> wrote:

>Joe Gordon wrote:
>>
>>
>> On Tue, Feb 17, 2015 at 4:19 AM, Sean Dague <sean at dague.net
>> <mailto:sean at dague.net>> wrote:
>>
>>     On 02/16/2015 08:50 PM, Ian Cordasco wrote:
>>      > On 2/16/15, 16:08, "Sean Dague" <sean at dague.net
>>     <mailto:sean at 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.