Add support for setting discovery arguments via python module paths about stestr HOT 3 OPEN

So while I agree this feature request would be nice to have I do really wonder how much use it would really have. It seems like a pretty uncommon use case to want to run tests on a package that's already been installed outside of where that code lives. It also depends on tests being packaged in the sdist, which isn't a guaranteed pattern. But, either way it likely won't harm anything and shouldn't be hard to implement, I think it's a good low hanging fruit for a new contributor.

As an aside the use case you're describing here is actually something that tempest supports natively already. This is part of the concept of tempest workspaces (see step 3 in: https://docs.openstack.org/tempest/latest/overview.html#quickstart ) That will create a self contained environment for running tempest from an installed tempest package. While the guide there recommends using tempest run after workspace creation, you can use stestr directly. (since tempest run is just calling it internally)

from stestr.

I just updated the title to be a bit more reflective of what the feature request is.

from stestr.

Thanks @mtreinish

To explain what we did is exactly as you mention in https://docs.openstack.org/tempest/latest/overview.html#quickstart :

tempest init our_platform1
tempest init our platform2
# etc...

And then for each platform we followed https://docs.openstack.org/tempest/latest/configuration.html#tempest-configuration
And we made a git repo of all this which contains the platforms configurations and the tempest tests to whitelist/blacklist depending on the platform.
Tempest and all openstack clients are in a python requirements.txt file of the repo, and after cloning the repo one just needs to pip install the requirements in a virtualenv and launch all tests or a specific test when he modified something on the platform, in order to check non-regression (we have a CI doing it automatically, but it's good practice that the operators of the platform check manually at ounce with specific tests targeted on the platform change before the CI launches all tests, just to revert fast in case of issues).

Now the issue with this is that tempest init created .testr.conf files with hard coded paths...
Any one who clones our repo has therefore non working paths once cloned as you can easily understand, since the virtualenvs have different paths.
So I'm making scripts to regenerate these .testr.conf files automatically, post git clone.

Once stestr accepts python module paths, what I'll do afterwards is raise a launchpad ticket on tempest (and os-testr) so that tempest init uses python module paths instead of hard coded paths when it generates the conf files (and so that it generates .stestr.conf files instead of .testr.conf files, but conversion is trivial).

Thanks a lot.

from stestr.