Open Stack

On Tue, 2015-04-28 at 10:40 -0700, Clint Byrum wrote:
> > No dice.  I don't want to have to parse the tox.ini directly.  We're
> > talking about automated tests here, by the way.
> 
> Why not? It's an ini file, with a stable interface.

Yes, but it's tox's perview.  Also, it's not just the command; I may be
building my own virtual environment to use, but there are other
environment variables typically set up by the test environment (e.g.,
PYTHONHASHSEED).  Also, there could be multiple tests to run, e.g., I
might need to run py27 and pep8.  With all of that, getting the proper
test setup programmatically becomes almost a bastardized
reimplementation of tox, and I'd *really* rather not do that.  As I say,
I'd love to just run tox; I just need it to use my virtualenv, not build
another.

> I'm sure you've thought more about this than me, so I apologize for
> sounding dense. However, I'm struggling to see where having to maintain
> two test harnesses is less complicated than the code above.

Well, we don't typically make all that many changes to the test harness
to begin with, so while it's not exactly the ideal situation, it's not
really all that hard to try to maintain both (though admittedly a bit
more error prone).  Also, run_tests.sh typically doesn't run all the
tests that tox is capable of running, and that's fine; as long as it
runs basic acceptance-type tests (e.g., unit tests and pep8), I'm happy.

I raised this issue before on the list some months ago…IIRC, it was when
someone had proposed removing run_tests.sh from nova.  I explained why I
needed it and pointed to the tox issue I had open.  As I recall, that
thread included some comments from some other operators that also wanted
to use run_tests.sh for basically the same reason we were: acceptance
tests on the virtual environment.  The result of that thread was to keep
run_tests.sh around for now.  I can say that, if the issue I reported
ever gets addressed, I'll happily drop run_tests.sh like a hot potato.
(Well, there's some other minor issue, having to do with odd characters
in path names, but I can just find a different way to encode the path
name to deal with that problem :)
-- 
Kevin L. Mitchell <kevin.mitchell at rackspace.com>
Rackspace