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.



             -Sean

    --
    Sean Dague
    http://dague.net

    __________________________________________________________________________
    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe:
    openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
    <http://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 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

Reply via email to