On Mon, Nov 18, 2013 at 4:02 PM, John Chilton <chil...@msi.umn.edu> wrote: > On Mon, Nov 18, 2013 at 9:55 AM, Peter Cock <p.j.a.c...@googlemail.com> wrote: >> On Mon, Nov 18, 2013 at 12:35 PM, Peter Cock <p.j.a.c...@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. > > I didn't implement any of this composite dataset stuff so I am just > guessing on best practices here, but is the right thing to do here > switch from 'basic' to 'auto_primary_file' ? Just generate a file that > just includes the content you want to display and set that as the > primary file - I think this might be better practice than overriding > display_data. If you want that file to a log if it is available that > is fine, if files are uploaded an optional log could be available and > you can provide a default fallback if unavailable in > generate_primary_file/regenerate_primary_file. If you do insist on > overriding display data, than you should at least allow fallback to > what the super class would do if (filename and filename != 'index'). >
I see, so my (dummy) primary file could just a small text file saying "This is a BLAST protein database." or similar - and that would let me reproduce the current behaviour? The only possible downside I can see right now is wondering what happens to existing histories containing old BLAST databases created with the current code... but that will sort itself out eventually with some user inconvenience. Who is the composite file architect (for their thoughts)? Regards, Peter ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
