Re: SPAdes for Debian
Andreas,
>> Python 2 and Python 3? Have you checked SPAdes functionality with
>> Python 3? spades.py itself is Python 3 friendly.
>
> Well, in Debian the according modules are selected automatically
> depending from the Python version. So if you run python3 the Python
> modules path is automatically set to the Python 3 modules (which are in
> the packages python3-yaml and python3-joblib. If you confirm that
> SPAdes works "better" with Python 3 I will adapt the according script in
> /usr/bin/spades to force python3 as interpreter. (The patch will remain
> the same.)
For SPAdes it does not matter whether it runs via python 2.x or 3.x.
So, you have checked and spades.py works after your changed via both
"python spades.py" and "python3 spades.py" ?
> For sure I do not intend to create an incompatibility with any
> non-Debian instances of SPAdes and it is definitely not in my interest
> to create packages you as developers do not like. However, specifically
> in the case of spades.py I feel confused as a user since this seems to
> be basically a wrapper around "spades.c" code.
Well, this is not a lightweight wrapper. Actually, spades.py
implements the whole pipeline - it prepares the configuration files,
creates the directories for intermediate files, runs the tools within
the pipeline, gracefully handles the errors (so even if some of the
tools inside the pipeline crash we can still make sure that the error
is properly reported into log file with appropriate stack trace) and
many other stuff. It's actually a part of SPAdes - the glue layer
between various tools. Check "src/spades_pipeline/*" for the sources
of this "wrapper" script :)
> Could you please
> elaborate about the reasons why you are "advertising" the script
> language in a way which may be needs to reverted in case at some time in
> time you consider rewriting the wrapper into Ruby, Haskell or whatever
> cool language (not that I personally would consider this sensible, just
> finding some examples).
The reasons (by now) are mostly historical. However, we cannot get rid
of ".py" extension now, because it would be incompatible change. This
might be a good change for SPAdes 4.0 though, but I have no idea when
this may happen, maybe within a year or two.
> And yes, I did not regarded the developer's way of running SPAdes. The
> Debian package (for the moment) supports only the users who do not
> intend to rebuild from code. Do you think it would make sense to
> support a development library?
No. The development version is intended for SPAdes developers only.
> choosing is that we will be able to force python3 via this wrapper if
> you would prefer this. Can you tell me any reason for a user who simply
> wants to do genome assemblies to pick from a set of Python interpreters?
We used to support many python versions simply because there are still
bunch of the users who have 2.4 installed (e.g. via old RedHat /
CentOS installations). And since this may be centralized server
installation, they would be unable to upgrade. So, we had to tune at
our side. Same for 3.x
> Does this mean there is a test suite included I just not detected? The
> point is that it does not need to be user friendly because we try to
> run it on behalf of our users
There is a testsuite, but it's not included into the release tarballs.
The problem is that in order to carefully test various assembler
features one usually needs quite big input files, etc. You can surely
download the reads from our website (e.g.
http://spades.bioinf.spbau.ru/spades_test_datasets/ecoli_sc/) and try
to assemble to make sure you obtain the same results as mentioned in
the comparison table at http://bioinf.spbau.ru/spades/
>> ext/tools/bwa - GPLv3. Slightly modified to make sure it compiles with
>> modern GCC's.
>
> My plan is to replace this by the Debian packaged version:
>
> $ apt-cache show bwa | grep ^Version
> Version: 0.7.5a-2
>
> which definitely compiles with latest gcc (and we actually provided
> patches to upstream in the past to let this happen). Do you think
> it is a bad idea to rather use bwa 0.7.5a than the code copy you are
> providing inside SPAdes?
I believe it should be fine. Now that we're renaming the binary into
"bwa-spades" in order not to clash with the system one. You may want
to patch this out :)
--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University
Reply to: