Open Stack

On 03/06/2013 06:53 AM, Alan Pevec wrote:
> 2013/3/6 Mark McLoughlin <markmc at redhat.com>
>>> The conclusion I'm coming to from the discussion is that by and large
>>> Python library maintainers try to avoid incompatible changes and they
>>> have commitments to stability built into their versioning schemes. We
>>> need to understand each library's versioning scheme and do e.g.
>>>
>>>    sqlalchemy>=0.7.8,<0.8
>
> Note that pip considers 0.8.0b2 <0.8 which already breaks API, we had
> one gate breakage when sqlalchemy pushed first 0.8 beta.
> Not sure what's the solution, currently we have in tools/pip-requres
> SQLAlchemy>=0.7.8,<=0.7.9 which should be updated now that 0.7.10 is
> the latest stable release.

Yes, I remember that well about when we tripped over it. Which is why 
the dependency is as funny as it is. Which again is why this is a *hard* 
problem.

People watching the gate yesterday will also notice that a lot of the 
breaks were because a dependency failed to installed, then another 
dependency later in the list had a shadow dependency which was > our max 
version of the first dependency, and boom.

Honestly, it feels like if we want to solve this for real, we're going 
to have to put a shim in front of pip so projects can define:

tools/os-requires:
sqlalchemy

and os-pip (or whatever) queries our requirements list, figures out what 
versions of sqlalchemy are allowed, and installs with that policy.

It would also mean that we'd stop having all these pip-requires sync 
changes that had to land in all the projects in the right order to 
stepwise through the gate.

	-Sean

-- 
Sean Dague
IBM Linux Technology Center
email: sdague at linux.vnet.ibm.com
alt-email: sldague at us.ibm.com