On Mon, Nov 18, 2013 at 12:35 PM, Peter Cock <p.j.a.cock(a)googlemail.com> wrote:
On Sun, Nov 17, 2013 at 8:30 AM, John Chilton wrote:
> With these change, I was able to write working functional tests for
> your tool using the template you outlined in the Trello card. ...
> I discovered no problems with auto_primary versus basic composite
> types here, just the things listed above.
Not for me though, even if I rename the masking "file" param to
avoid the ambiguous "file" parameters ...
I find that changing the order of the <extra_files> tags in the test seems
to alter the failure - which supports my hunch that something is
scrambling the order of the extra files, so that it fails to compare the
generated blastdb.phr with the provided four_human_proteins.fasta.phd
John's replies via Twitter:
@pjacock Hard to argue with @travisci but your makeblastdb
test works unmodified on my box and I can reorder the extras.
I'm still looking..
@pjacock Got it, you are overriding display_data in blast DB
datatypes. This breaks much! Is how the test framework/API/etc
There may be trouble ahead... the current display_data override
is to give some meaningful output to the user when they click
the "eye ball" icon for a BLAST database - rather than something
unhelpful and scary like a blank page.
A more slick option would be to override display_data to run
blastdbcmd live, but that means a run time dependency of the
datatype definition on (a specific version of) the BLAST+ binaries
- which could be problematic.
I had considered capturing the makeblastdb stdout to a file as
blastdb.log and having that as the (human viewable) primary
file of a composite datatype - but that would cause trouble if and
when I manage to support user uploaded BLAST databases.