[Biopython-dev] Running Biopython tests on windows xp
bsouthey at gmail.com
Thu Jan 15 03:10:30 UTC 2009
On Wed, Jan 14, 2009 at 5:27 PM, Peter <biopython at maubp.freeserve.co.uk> wrote:
> On Wed, Jan 14, 2009 at 10:48 PM, Bruce Southey <bsouthey at gmail.com> wrote:
>> Using IDLE, 'from Bio.Restriction import *' works correctly.
>> These ones are failures to find the correct biopython installation. Both
>> 'python setup.py test' and 'python run_tests.py' are assuming that I have
>> built from source and everything is in the local directory. But that
>> assumption is wrong since I used the Biopython binary installer so
>> technically the tests I run are invalid.
> I think I understand what's going on now. All these failures are
> essentially due to the unusual and unexpected setup on your machine
> (or for the SCOP tests, the line endings).
I do not see it as unusual as it does follow the instructions. But
these clearly need some enhancement to address perhaps a variation of
one of the options below.
I am now curious about what happens under Linux distros because these
may have the same issue.
> You still didn't explain
> how/where you installed the test scripts etc, but what I think is
> happening is the following:
> You're official installation (including the compiled C code) create
> using the Windows Installer is in one place, say under
> C:\XXX\site-packages for the sake of discussion.
> You've unpacked the source code in another location, and are trying to
> run the test suite there. This set of files will NOT have the
> compiled C code - and thus running some of the tests via run_tests.py
> will fail. If you run individual test_XXX.py files this should use
> the system installed files under C:\XXX\site-packages and so the test
> should work.
The installation documentation is lacking at least for the binary
installer. Depending on what happens, I will write down this
Would be be a hassle to include the tests with the binary installer?
At least of the tests should work if they are run from that directory.
> It would be a bit of a hack, but you can probably overcome this by
> manually copying the installed compiled modules from
> C:\XXX\site-packages into the unpacked source code (under a suitably
> named build sub directory), or moving the Test suite next to the
> installed code.
While this would work for the binary installer, I do not think it is
suitable solution for building it from source - especially if someone
has the binary installer and is building but not necessary installing
> Alternatively, you could try editing run_tests.py to comment out the
> path "magic" so that is just uses the system installation of Biopython
> (rather than trying to use the local copy it expects you to have just
> built from source), i.e. try commenting out these two lines in
> run_tests.py found near the start of the main function:
> sys.path.insert(1, source_path)
> sys.path.insert(1, build_path)
I think the best solution is to fix this part because these assume the
location of the source and build directories even if these are not
really present. I would suggest we add a new commandline option that
causes the source_path and/or build_path variables to be undefined
forcing Python to use the installed versions. Passing a user-specified
path is also an option but these can get long.
> However, I'm no longer surprised that the C code tests are failing,
> and don't think this is a bug per se.
Agreed - just a case that has not been addressed yet.
>> For the SCOP tests, this is as you say, a 'end of line' issue between
>> windows and Linux. I opened 'and dir.cla.scop.txt_test' with wordpad and
>> saved it with a new name. The line from testIndex in test_SCOP_Cla.py that
>> gave the error index['d4hbia_'] works with the new file but not the old
> Good to confirm that. If you spot an easy cross platform fix so that
> the SCOP code can cope with either line ending that would be good, but
> I didn't consider this worth sending much time on.
When I get to my system, I will see if my Linux system will accept the
file correctly because the other SCOP tests did work. If I get time I
will try to look at that as I looked at the function and I think it is
just the way the file is being used.
>> I also installed reportlab and biosql and these pass the tests (except for
>> the mysql warning with Biosql that Peter reported).
> Good. Out of interest, which BioSQL warning are you talking about?
Sorry, I do not have that handy but it is depreciation one for a
setting that will be gone in MySQL 5.2.
More information about the Biopython-dev