On 01/13/2015 12:39 PM, Zane Bitter wrote:
On 13/01/15 10:01, Jeremy Stanley wrote:
On 2015-01-13 07:46:38 -0500 (-0500), Sean Dague wrote:
Why doesn't rally just remove itself from projects.txt, then there
would be no restrictions on what it adds.

I second this recommendation. If Rally wants to depend on things
which are not part of OpenStack and not required to run or test
OpenStack in an official capacity (and since it's not an official
OpenStack project it's entirely within its rights to want to do
that), then forcing it to comply with the list of requirements for
official OpenStack projects is an unnecessarily restrictive choice.

FWIW I don't really agree with this advice. The purpose of
openstack/requirements is to ensure that it's possible to create a
distribution of OpenStack without conflicting version requirements, not
to force every project to use every dependency listed. As such, some
co-ordination around client libraries for related projects seems like it
ought to be an uncontroversial addition. (Obviously it's easy to imagine
potential additions that would legitimately be highly controversial, but
IMHO this isn't one of them.) Saying that we require people to use our
tools to get into the club but that our tools are not going to
accommodate them in any way until they are in sounds a bit too close to
"Go away" to my ears.


That said, I'd like to suggest another possible workaround: in Heat we
keep resource plugins for non-official projects in the /contrib tree,
and each plugin has it's own setup.cfg and requirements.txt. For example:


So the user has the option to install each plugin, and it comes with its
own requirements, independent of the main Heat installation. Perhaps
Rally could consider something similar.

Seems like a very reasonable solution to me.

Thanks for bringing it up,

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to