Open Stack

Agreed, we are going to expand it and work on figuring out how to test against multiple versions. It does work with 0.8 and it seems even like 0.9 works fine also. But all compatible also means I can't guarantee 0.10 (if it comes out) will work since afaik semver means sqlalchemy could still break things when it's  < 1.0. Anyone got a time machine I can use to check the future ;-)

It seems simple to have variations of venvs (or something similar) that taskflow tox.ini can have that specify the different 0.7, 0.8, 0.9, when sqlalchemy 1.0 comes out then this should become a nonissue (hopefully). I will bug the infra folks to see what can be done here (hopefully this is as simple as it sounds). 

Sent from my really tiny device...

> On Jan 5, 2014, at 8:22 AM, "Clint Byrum" <clint at fewbar.com> wrote:
> 
> I've skimmed the rest of the thread and not seen something mentioned
> that seems like it matters a lot. If I missed this suggestion buried
> deep in the ensuing discussion, I apologize for that.
> 
> Since TaskFlow wants to be generally consumable and not only driven as
> an OpenStack component, it should not be following global requirements.
> It should actually expand its SQL Alchemy compatibility to all supported
> versions of SQLAlchemy. Ideally it would have a gate for each major
> version of SQL Alchemy that upstream supports.
> 
> Otherwise it will never even be able to work with any project that
> doesn't share its SQL Alchemy version pin.
> 
> Excerpts from Joshua Harlow's message of 2014-01-03 08:37:17 -0800:
>> So taskflow was tested with the version of sqlalchemy that was available and in the requirements at the time of its 0.1 release (taskflow syncs it's requirements from the same global requirements). From what I remember this is the same requirement that everyone else is bound to:
>> 
>> SQLAlchemy>=0.7.8,<=0.7.99
>> 
>> I can unpin it if this is desired (the openstack requirements repo has the same version restriction). What would be recommended here? As more code moves to pypi reusable libraries (oslo.db when it arrives comes to mind) I think this will be hit more often. Let's come up with a good strategy to follow.
>> 
>> Thoughts??
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev