[openstack-dev] [horizon][neutron] tools/tox_install changes - breakage with constraints
thomas.morin at orange.com
Thu Mar 15 09:15:38 UTC 2018
Doug Hellmann, 2018-03-14 23:42:
> We keep doing lots of infra-related work to make it "easy" to do
> when it comes to
> managing dependencies. There are three ways to address the issue
> with horizon and neutron, and none of them involve adding features
> to pbr.
> 1. Things that are being used like libraries need to release like
> libraries. Real releases. With appropriate version numbers. So
> that other things that depend on them can express valid
> 2. Extract the relevant code into libraries and release *those*.
> 3. Things that are not stable enough to be treated as a library
> shouldn't be used that way. Move the things that use the
> code as library code back into the repo with the thing that they
> are tied to but that we don't want to (or can't) treat like a
What about the case where there is co-development of features across
repos ? One specific case I have in mind is the Neutron stadium where
we sometimes have features in neutron repo that are worked on as a pre-
requisite for things that will be done in a neutron-* or networking-*
project. Another is a case for instance where we need to add in project
X a tempest test to validate the resolution of a bug for which the fix
actually happened in project B (and where B is not a library).
My intuition is that it is not illegitimate to expect this kind of
development workflow to be feasible; but at the same time I read your
suggestion above as meaning that it belongs to the real of "things we
shouldn't be doing in the first place". The only way I can reconcile
the two would be to conclude we should collapse all the module in
neutron-*/networking-* into neutron, but doing that would have quite a
lot of side effects (yes, this is an understatement).
More information about the OpenStack-dev