On Fri, Jan 3, 2014 at 3:13 PM, Sean Dague <s...@dague.net> wrote: > On 01/03/2014 02:44 PM, Doug Hellmann wrote: > >> >> >> >> On Fri, Jan 3, 2014 at 12:45 PM, Joshua Harlow <harlo...@yahoo-inc.com >> <mailto:harlo...@yahoo-inc.com>> wrote: >> >> Ok, I think I'm fine with that (although not really sure what that >> entails). >> >> What does the living under the 'oslo program' change? >> >> Does that entail getting sucked into the incubator (which seems to >> be what >> your graduating link is about). >> >> I don't think its a good idea for taskflow to be in the 'incubator'. >> Taskflow is meant to be just like any other 3rd party library. >> >> >> No, as we discussed in Hong Kong, there's no reason to add taskflow to >> the incubator. >> >> Whether or not it needs to be part of the oslo program (or any other >> program) is a separate question. I'm not opposed to bringing it in, but >> didn't see the point when it came up at the summit. >> >> I understand that moving taskflow into oslo would avoid the policy >> decision we have in place to not do symmetric gating on unreleased >> versions of things not "owned" by the OpenStack project. However, I >> don't know if we want to be testing against the git head of libraries no >> matter where they live. As fungi pointed out on IRC, gating against >> pre-release versions of libraries may allow us to reach a state where >> the software works when installed from git, but not from the released >> packages. >> >> It seems safer to gate changes to libraries against the apps' trunk (to >> avoid making backwards-incompatible changes), and then gate changes to >> the apps against the released libraries (to ensure they work with >> something available to be packaged by the distros). There are lots and >> lots of version numbers available to us, so I see no problem with >> releasing new versions of libraries frequently. >> >> Am I missing something that makes that not work? >> > > Requirements wedging. > > Because of entry points any library that specifies any dependencies that > OpenStack components specify, at incompatible levels, means that library > effectively puts a hold on the rest of OpenStack and prevents it from being > able to move forward. >
I have considered changing stevedore so it uses entry points to find plugins, but then handles the import itself specifically to eliminate the requirements checks for plugin dependencies enforced by pkg_resources. So far I haven't convinced myself that it's a good idea, but I'm open to discussion. :-) > > Which means every time we need to then change a library dependency it's > going to require triggering a release, solely to change library > dependencies. > > This is the giant disaster that we created global requirements to avoid, > so that we have one nob to turn. > > The only other option is that libraries we own (stackforge / oslo), for > condition to be included in global- requirements, *can never* specify a > maximum version of any dependency (and I really mean never), and can never > specify a minimum greater than current global requirements. That seems like a more appealing solution than testing against unreleased versions via git checkouts. It is is also an approach we could encourage authors of libraries we don't own to use. Doug > > > -Sean > > -- > Sean Dague > Samsung Research America > s...@dague.net / sean.da...@samsung.com > http://dague.net > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev