On Mon, Nov 18, 2013 at 12:35 PM, Peter Cock <p.j.a.cock@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: https://twitter.com/jmchilton/status/402436500131807232
@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..
https://twitter.com/jmchilton/status/402446372231581696
@pjacock Got it, you are overriding display_data in blast DB datatypes. This breaks much! Is how the test framework/API/etc access datasets.
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. Thanks, Peter