On 01/03/2014 03:30 PM, Doug Hellmann wrote:



On Fri, Jan 3, 2014 at 3:13 PM, Sean Dague <s...@dague.net
<mailto: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>
        <mailto: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. :-)

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.

This entire taskflow block wouldn't have been a problem if it wasn't loaded with entry points.

        -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

Reply via email to