On 01/03/2014 05:10 PM, Ivan Melnikov wrote:
On 04.01.2014 01:29, Sean Dague wrote:
On 01/03/2014 04:17 PM, Doug Hellmann wrote:
[...]
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.
[...]
But sometimes humans are not wrong. For example, no released TaskFlow
version really works with SQLAlchemy >= 0.8 -- that was fixed only
recently (https://review.openstack.org/#/c/62661/).
I consider requirements to be part of the code, so if they are too
strict (or too broad), that must be fixed, in a usual opensource way:
via filing bug report, suggesting patch and so on.
Requirements should reflect reality, especially for libraries that are
intended to be useful outside of OpenStack, too. For example, current
TaskFlow requirement for SQLAlchemy is too strict, so we'll fix that,
and release new version with that fix.
Well part of the problem is because of it being a dependency of a
dependency, our global requirements process couldn't explore whether or
not it functioned in a real environment.
Which brings us back to the idea of making this a project that works in
the integrated gate.
It's also kind of problematic that apparently the introduction of
taskflow actually caused a regression from Havana (which the distros
managed to make work with sqla 0.8 even though it wasn't in global
requirements, but this apparently would have broken).
And the next question is when is a sqla 0.9 compatible version going to
be out there? Because we can't even explore allowing openstack to use
sqla 0.9 until taskflow does, again because it's a blocking requirement.
It's exactly these kind of lock step problems that we avoid with the
rest of openstack by making it an integrated gate with global
requirements sync. But that we can't really handle with the library model.
-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
