[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