[openstack-dev] [requirements] - taskflow preventing sqla 0.8 upgrade

Sean Dague sean at dague.net
Fri Jan 3 21:29:01 UTC 2014

On 01/03/2014 04:17 PM, Doug Hellmann wrote:
> On Fri, Jan 3, 2014 at 4:08 PM, Sean Dague <sean at dague.net
> <mailto:sean at dague.net>> wrote:
>     On 01/03/2014 03:30 PM, Doug Hellmann wrote:
>         On Fri, Jan 3, 2014 at 3:13 PM, Sean Dague <sean at dague.net
>         <mailto:sean at dague.net>
>         <mailto:sean at dague.net <mailto:sean at dague.net>>> wrote:
>              On 01/03/2014 02:44 PM, Doug Hellmann wrote:
>                  On Fri, Jan 3, 2014 at 12:45 PM, Joshua Harlow
>                  <harlowja at yahoo-inc.com <mailto:harlowja at yahoo-inc.com>
>         <mailto:harlowja at yahoo-inc.com <mailto:harlowja at yahoo-inc.com>__>
>                  <mailto:harlowja at yahoo-inc.com
>         <mailto:harlowja at yahoo-inc.com>
>                  <mailto:harlowja at yahoo-inc.com
>         <mailto:harlowja at 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. :-)
>     Well, about 1/3 of our requirements wedges are actually completely
>     entry point related. They were a class of problems we never had
>     before we switched to entry points.
> That's what made me think of the solution. But isn't setuptools in fact
> telling us that somehow the versions of things we expected to have
> installed are no longer installed and so something *is* broken (even if
> the versions of the installed libraries work together).

It actually tells us that a human, somewhere, decided that their 
software did not work with some combination of other software, and that 
we are no longer able to correct their mistaken assumptions.

There is a reason the Linux distros don't blindly follow what libraries 
say they depend on, because humans are foulable, and can only look 
backwards and not forwards in time.


Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com

More information about the OpenStack-dev mailing list