Hi all, An eagle eyed user has just spotted a bug in our BLAST wrappers and/or the Galaxy framework itself. 1. Run BLASTN (wrapper version v0.1.00 which is currently on the Test Tool Shed) 2. Select BLASTXML output, execute 3. While running click the "i" icon, which wrongly reports: Format:tabular 4. Check the "repeat", which correctly has XML output 5. Once finished, notice the output is XML, but Galaxy labelled it "tabular" 6. Workaround via the "pencil" icon, correct the datatype to "blastxml". This happens both on our production server: $ hg summary parent: 11218:26f58e05aa10 release_2013.11.04 Galaxy stable release for 2013.11.04. branch: stable And also on my development server with galaxy-central: $ hg summary parent: 13675:bc1173309bd5 tip Variable name fix for the tool shed's install and test framework. branch: default This used to work perfectly. We've not changed this area of the code in the BLAST wrappers directly - it uses a default output type of "tabular" and the <change_format> tag - expanding the macro we have: <outputs> <data name="output1" format="tabular" label="${blast_type.value} $query.name vs @ON_DB_SUBJECT@"> <!-- <expand macro="output_change_format" /> --> <change_format> <when input="out_format" value="0" format="txt"/> <when input="out_format" value="0 -html" format="html"/> <when input="out_format" value="2" format="txt"/> <when input="out_format" value="2 -html" format="html"/> <when input="out_format" value="4" format="txt"/> <when input="out_format" value="4 -html" format="html"/> <when input="out_format" value="5" format="blastxml"/> </change_format> </data> </outputs> What has changed recently in the NCBI BLAST wrappers is that input parameter "out_format" is now nested within a conditional block. Other tools using <change_format> seem to still work fine: https://github.com/peterjc/pico_galaxy/tree/master/tools/seq_filter_by_id Can anyone testing the BLAST+ update on the Test Tool Shed reproduce this? Any thoughts on the cause and fix? I have to attend a meeting now, so I've not dug any deeper yet... Regards, Peter