Hi Hannes,
many thanks for your quick response.
On Tue, Apr 08, 2014 at 04:07:24PM +0100, Hannes Ponstingl wrote:
Thanks for your interest in SMALT. I have cleaned up the test
routines for the installation/distribution somewhat with the latest
release 0.7.6 which you can download from smalt.sourceforge.net.
Yes, this is where we are taking the source from.
1. Since we always want to honour scientist work we would like to
add some citation information to the package metadata (you can
see the result when visiting the page above). Are there any
publications about SMALT?
There still is no publication describing SMALT - although a number
of high-profile papers have appeared that use it. So if you could
mention smalt.sourceforge.net and my name and affiliation in the
citation info. I would let you know once I have the paper accepted.
The author and homepage are usual metadata in Debian packages.
2. The installation puts a set of binaries next to the main binary
smalt in the users path (basqcol, fetchseq, ...). Is it correct
that in principle only smalt is the user interface and these
additional binaries are only helpers called by smalt?
If this is the case I tend to use a wrapper script /usr/bin/smalt
which calls these exectuables from /usr/lib/smalt. This would
avoid potential name space conflicts with generic names like
readstats.
Yes, smalt is the only user interface. The other binaries can be
used to generate simulated data and to inspect files ets. They are
undocumented and I should probably remove them from the installation
to avoid confusion. Version 0.7.6 should have been cleaned up
somewhat in that respect. There is no need for a wrapper and smalt
does not call any other binaries.
OK, this simplifies things.
3. What is the role of the Python script the installation procedure
is moving to /usr/share by default. With the exception of SAM.py
the scripts seem to belong to a test suite. Usually in Debian
Python scripts are installed in a different PATH. Is SAM.py also
a user application or just a helper for the smalt binary?
The python scripts are for testing during development except for a
number of installation test drivers *_test.py that are packaged in
the distribution. Please refer to smalt/test/Makefile.am which is
also the test harness (make check). Let me know if you need help
with that.
I get the tests running now on my workstation installation. However,
when I'm running the build process in a clean chroot (which is mandatory
for a package build) I seem to miss some precondition. I have inspected
the *.py sources and guessed from
from formats import Cigar
that BioPython is needed. So I added this to the chroot but the tests
are not working better. So most probably I'm lacking some dependency
which is available on my workstation - but which one?
Also the last test is failing. I get:
PASS: splitReads_test.py
PASS: results_split_test.py
PASS: ouform_cigar_test.py
PASS: sample_test.py
PASS: cigar_test.py
PASS: mthread_test.py
ERROR when mapping: returned with code 1
FAIL: bam_cigar_test.py
=================================
1 of 7 tests failed
Please report to hp3@sanger.ac.uk
=================================
I think this might also be connected to some missing dependency.
4. In Debian we try to run any test suite if available but I somehow
failed to find the documentation how to exactly run the full
test suite.
The test suite is run with 'make check' from the distribution (make
dist). Binaries are wrapped with python drivers in
smalt/test/*_test.py. The harness is the automake 'make check'
facility.
Thanks - at least the test procedure is started now.
Please let me know if you nee more help.
I'm happy about your very constructive response.
Kind regards
Andreas.