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.mitch...@rackspace.com> Rackspace __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
