On 01/03/2014 04:17 PM, Doug Hellmann wrote:
On Fri, Jan 3, 2014 at 4:08 PM, Sean Dague <[email protected]
<mailto:[email protected]>> wrote:
On 01/03/2014 03:30 PM, Doug Hellmann wrote:
On Fri, Jan 3, 2014 at 3:13 PM, Sean Dague <[email protected]
<mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
On 01/03/2014 02:44 PM, Doug Hellmann wrote:
On Fri, Jan 3, 2014 at 12:45 PM, Joshua Harlow
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>__>
<mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>__>__>> 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
--
Sean Dague
Samsung Research America
[email protected] / [email protected]
http://dague.net
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
