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:

http://git.openstack.org/cgit/openstack/heat/tree/contrib/heat_barbican

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.

cheers,
Zane.

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to