Hello All, I have dedicated a considerable amount of time to track down some of the errors that show up in windows. The good news is that none of the errors come from pygr. The bad news is that *all* the errors that I've seen so far came from the testing framework itself! This makes it a bad news in that it means that a rework is probably necessary.
To this end I have partially reworked many of the test modules. You can see what I have done by getting my repository at: git clone http://atlas.bx.psu.edu/git/pygr-test2.git/ The new tests are located in the tests2 directory. The following issues have been worked on: - no more driveby-file-bombing: test data files live in the data directory, all temporary files are created in the temp subdirectory (that will be created automatically), the only file that I was unable to move to temp is the downloaded file. - no more access errors on windows (due to removing files without them being closed, windows would complain) - simpler test running, each test module can be run on its own to generate high verbosity output, or it can be run via the runtest.py - removed dependency on nose, tests are based on unittest. I found the old protest.py to be a little convoluted, since I don't know that the reason for running every testmodule in a new python interpreter was I just bypassed that, the advantage is that this makes it a mere 10 or so lines of actual code. - added more meaningful docstrings to each test. The job is not finished but I'm putting it out here to get some feedback. Other issues: - pygr.Data really needs a standalone and isolated namespace, I have spent a few days trying to make one but finally gave up, there are lots redirections there, with global names etc that makes understanding the code difficult. Currently, I am using the path of least resistance, I simply overwrite the PYGRDATAPATH environment variable to force it to use a different path. - I think some of the tests would be better in a doctest format. For example the pygrdata_test that for now is only partially ported should be intermingled with a narrative that would also explain what the lines of code actually do. This could then be rendered into documentation thus serving a dual purpose. One of the reasons I started this is to understand better what every component does. In the end I had some fun with it and I am willing to spend more time with it, provided this is something that is positively received. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pygr-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pygr-dev?hl=en -~----------~----~----~----~------~----~------~--~---
