[openstack-dev] Dependency version pinning [was Re: Pyparsing 2.0 breaking jenkins jobs]
Johannes Erdfelt
johannes at erdfelt.com
Wed Mar 6 02:13:25 UTC 2013
On Tue, Mar 05, 2013, Mark McLoughlin <markmc at redhat.com> wrote:
> I've some notes below, but the tl;dr is that unless we "cap" our
> requirement ranges we're going to be hit by incompatible updates. Each
> project has a different policy on how their version number and we'll
> actually need to talk to each project we use about their policy.
>
> What we want is e.g.
>
> sqlalchemy>=0.7.8,<0.8
>
> but only after talking to sqlalchemy to confirm that they will bump the
> minor number iff they are making incompatible changes.
And iff all of the recursively resolved dependencies also adhere to
this.
Which is a pretty big if.
> What we need is a combination of (a) the openstack/requirements repo,
> (b) capping our requirements as described above and (c) a PyPI mirror
> that is only refreshed if the refresh doesn't break the gate
If we cap all of the requirements, then c is only there to ensure the
gate isn't broken by some dependency (direct or indirect)?
> - A new operator (sometimes known as the 'spermy' operator in Ruby)
> is being introduced. In PEP426, it's expressed as:
>
> Requires-Dist: foo (1.2)
>
> but in pip-requires, it's likely to be:
>
> foo~>1.2
>
> any version in the 1.x series greater than 1.2 satisfies this. If
> you wanted 1.2.3 or later but also to avoid 2.x, you'd do:
>
> foo~>1.2,>=1.2.3
I'll have to find the discussion and express my confusion that the
greater-than symbol is being used in an operator that explicitly doesn't
match all newer versions (for instance, 2.x in your example).
> - Not all projects will use semantic versioning, but it is expected
> that all projects have some policy on how their version number will
> reflect incompatible updates. There is currently no metadata that
> projects can use to publish this information, so we actually need
> to talk to each upstream individually.
What happens if an upstream project doesn't have a policy for whatever
reason?
Do we deal with the possible breakage? Migrate to another project that
is a easier to work with?
JE
More information about the OpenStack-dev
mailing list