restructuring lib-python-2.3.4 / testing
Hi pypy-dev, for various reasons it seems like a good idea to move to a slightly modified directory structure regarding our "compat 2.3.4 library" and tests. The idea is to put the completely unmodified standard python library into: lib/python-2.3.4 and put test-wrapping configuration/hacks etc.pp. in lib/ instead of modifying an otherwise unmodified tree. The changed tests and library modules we have in pypy/lib could reside where they are now although it might be clearer to put them into lib/python-2.3.4-modified instead. This is probably a question of how version independent our modifications really are. Today we also changed the way compliance tests are run (by default, you get the old behaviour with '-E') because we want to move on with getting a complete overview of test failures. If you run py.test (or pypy/test_all.py) in the python-2.3.4 library then your test runs will get recorded into a new 'result' directory. With the above proposed location i would suggest to put this result directory into: lib/python-2.3.4-testresult/ If there are no objections (even better: agreement :-) i am doing that this night or tomorrow. cheers, holger
Hi Holger, On Wed, Apr 27, 2005 at 03:31:38PM +0200, holger krekel wrote:
With the above proposed location i would suggest to put this result directory into:
lib/python-2.3.4-testresult/
If there are no objections (even better: agreement :-) i am doing that this night or tomorrow.
In complement with what you said: the idea here is that if you go to lib-python-2.3.4/test/ and run py.test (with or without specific test names), by default the test is run "the slow way" (i.e. by running py.py test_xyz.py) and its output is recorded in a file result/test_xyz.txt, together with some information like revision number, date/time, etc. Holger: I am now thinking that you were absolutely right when you suggested one test-result directory per user. I re-ran some tests, now I do an 'svn up', and I get conflicts, of course. One directory per user@hostname would even be better. However, this will create a whole lot of data, so it might be best to put it at some place outside the pypy/dist root, if possible... Armin
Hi Armin, On Fri, Apr 29, 2005 at 10:18 +0100, Armin Rigo wrote:
On Wed, Apr 27, 2005 at 03:31:38PM +0200, holger krekel wrote:
With the above proposed location i would suggest to put this result directory into:
lib/python-2.3.4-testresult/
If there are no objections (even better: agreement :-) i am doing that this night or tomorrow.
In complement with what you said: the idea here is that if you go to lib-python-2.3.4/test/ and run py.test (with or without specific test names), by default the test is run "the slow way" (i.e. by running py.py test_xyz.py) and its output is recorded in a file result/test_xyz.txt, together with some information like revision number, date/time, etc.
Holger: I am now thinking that you were absolutely right when you suggested one test-result directory per user. I re-ran some tests, now I do an 'svn up', and I get conflicts, of course.
Sure enough.
One directory per user@hostname would even be better. However, this will create a whole lot of data, so it might be best to put it at some place outside the pypy/dist root, if possible...
If you put it outside of dist then the usual pypy checkout will not contain that directory, alas. For the time being, we should either live with the conflicts (not so nice) or move it to a user@hostname directory. This will also reduce the diffs, making 'svn up' rather cheap in terms of network bandwidth. Eventually, we want to have a 'sendreport' option that sends a report to codespeak where it gets integrated into an HTML view. But that is not going to happen in the next days so i suggest to just move to the user@hostname directory and move the current stuff to 'mixed@mixed'. cheers, holger
Hi Holger, On Fri, Apr 29, 2005 at 11:42:27AM +0200, holger krekel wrote:
If you put it outside of dist then the usual pypy checkout will not contain that directory, alas.
Yes, that was my intent. If we have 6 or 7 subdirectories with 1.5MB of text each (7MB total disk usage in working copy), it makes a check-out heavy, particularly for people who just want to grab the current version and play a bit with it.
For the time being, we should either live with the conflicts (not so nice) or move it to a user@hostname directory. This will also reduce the diffs, making 'svn up' rather cheap in terms of network bandwidth.
Right, so maybe we shouldn't care about the 'svn co' cost.
is not going to happen in the next days so i suggest to just move to the user@hostname directory and move the current stuff to 'mixed@mixed'.
Ok. Armin
On Fri, Apr 29, 2005 at 11:13 +0100, Armin Rigo wrote:
Hi Holger,
On Fri, Apr 29, 2005 at 11:42:27AM +0200, holger krekel wrote:
If you put it outside of dist then the usual pypy checkout will not contain that directory, alas.
Yes, that was my intent. If we have 6 or 7 subdirectories with 1.5MB of text each (7MB total disk usage in working copy), it makes a check-out heavy, particularly for people who just want to grab the current version and play a bit with it.
For the time being, we should either live with the conflicts (not so nice) or move it to a user@hostname directory. This will also reduce the diffs, making 'svn up' rather cheap in terms of network bandwidth.
Right, so maybe we shouldn't care about the 'svn co' cost.
Maybe we should do the following: svn ps 'svn:ignore' 'report' lib-python-2.3.4/test and then cd lib-python-2.3.4/test svn co http://codespeak.net/svn/pypy/testresult result and within that we have user@hostname directories. An 'svn co pypy-dist' or 'svn up pypy-dist' would not retrieve the test report files. you have to explicitely 'svn co/up report' which we could of course automate (at least on systems that have a 'svn' binary in their path). What do you think? cheers, holger
Hi, On Fri, Apr 29, 2005 at 12:39:10PM +0200, holger krekel wrote:
cd lib-python-2.3.4/test svn co http://codespeak.net/svn/pypy/testresult result
and within that we have
user@hostname
directories. An 'svn co pypy-dist' or 'svn up pypy-dist' would not retrieve the test report files. you have to explicitely 'svn co/up report' which we could of course automate (at least on systems that have a 'svn' binary in their path).
Done. If you just run py.test now, all the tests are skipped and you get a nice explanation about what you should do to retreive the 'result' directory manually. This way, it is by default kept out of the way, and we can feel free to check-in lots of stuff in there without worrying about it getting part of a normal 'svn co' of the 'dist' root. Armin
Hi all, On Fri, Apr 29, 2005 at 10:18:25AM +0100, Armin Rigo wrote:
In complement with what you said: the idea here is that if you go to lib-python-2.3.4/test/ and run py.test (with or without specific test names),
In addition: you should say py.test -D to run all the tests including the ones marked as disabled (this is usually what you want now). Also note that test_mutants eats the KeyboardInterrupt that is supposed to kill it after 15 minutes. Oups. Armin
participants (3)
-
Armin Rigo -
holger krekel -
hpk＠trillke.net