On Mon, Dec 21, 2009 at 10:11 +0100, Adam wrote: > holger krekel wrote: > > > It makes py.test install as > > > > py.test # if python executable has basename 'python' > > py.test3 # if python executable has version_info >= (3,0) > > py.test2.x # if python executable has basename 'python2.x' (x in > > '4567') py.test-jython # if we are running on jython2.5 > > py.test-pypy # if we are running on pypy > > > > does this make sense to you, objections? > > I don't know how easy it will be to get this to work with > debian's python-setup (or for any other distributor).
good point. OTOH they anyway modify the setup.py anyway so it's easy to implement their policy. I believe python3 is currently the standard so they probably should do 'py.test3' at least ... (not sure who is doing py.test debian packaging currently, btw) > > It does for me because > > i can more easily run tests with various interpreters. > > I think it is rather limited. If I want to know if my program has > interpreter dependant bugs I have to run all of the py.tests and compare > the outputs manually. > > What is the advantage of "py.test3" over running "py.test --tx > popen//python3"? ... it wouldn't work as py.test cannot currently do dist-testing across python2/python3 barriers ... > Maybe instead add a shortcut for the "--tx popen"s? > > Like "py.test -i3,2.4,j,pypy" to run the tests with many different > interpreters one after each other. I agree that this is the way to go. py.test's current dist-testing model has some limitations which can partially get in the way. Most notably it is the invoking python interpreter context that determines which tests are collected and distributed - e.g. test modules that produce a skip during import would never get send to ther other side. The other bit is that it might not be easy to discover all interpreters automatically. That being said, i am considering to actually follow your suggestion and implement the '-i' option. And also provide a py.test3 for python3. If you specify interpreters that don't exist what would you like py.test to do? Bail out up-front or produce skips or ..? cheers & thanks, holger _______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev
