[Biopython-dev] Running Biopython tests on windows xp
biopython at maubp.freeserve.co.uk
Thu Jan 15 12:46:21 UTC 2009
>> 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.
There are no instructions on how to install Biopython on Windows using
the provided installer and then run the unit tests - so I don't
understand what you mean by you followed the instructions. If the
installer came with the unit tests then this would be sensible.
Right now the only documented way to run the unit tests is part of an
installation from source.
>> 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?
I don't know enough about distutils to answer that. So the short
answer is yes, it might be a hassle.
> 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
> from source.
The hack suggested was specifically for combining the installed files
from the Windows installer with the test suite by hand - you don't
need to do anything special if you are building from source. The
current run_tests.py should work perfectly for anyone building from
source (on Windows, Linux and Mac). You can (and ideally should)
build biopython, and then run the tests BEFORE installing it.
>> 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.
If you are building from source this is a safe assumption (and in fact
the code does check they exist). We WANT to run the tests using the
just built and not yet installed files!
> 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.
Yes, an option to run_test.py to use the system installed version of
Biopython could solve this particular situation. Alternatively, and
perhaps more simply for the end user, we could add a prompt if there
is no build directory to ask the user if they want to run the tests
using an already installed version of Biopython. I might have time to
come up with a patch for this...
>> 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.
>>> 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.
You might be referring to BioSQL Bug 2568,
More information about the Biopython-dev