I think introducing a new a type like mutect.fasa or something is probably the better idea here. You can create a tool that creates this datatype and your main mutect tool wrapper can then take an input of type <param name="input" type="data" format="fasta,mutect.fasta"... and only re-index when a vanilla fasta is passed in.
If you did modify the existing fasta datatype - those changes would not really be pulled in as part of tool shed installs say - and I would be hesitant to collect extra metadata for every fasta datatype in the core code for a single application.
Hope this helps, -John
On Thu, Jan 15, 2015 at 1:03 PM, Marco Albuquerque marcoalbuquerque.sfu@gmail.com wrote:
Hello Galaxy,
I have a small dilemma regarding the fasta datatype.
Currently, to my knowledge, the fasta datatype does not specify any metadata. I was curious how I should go about changing the fasta datatype if I wanted to include the .fai and .dict as metadata? Basically I want to avoid unnecessary recreating of the same file done automatically by MuTect. It seems very inefficient to have to produce these files every time a user were to call MuTect in galaxy (I.e. MuTect can't find them, so it makes them itself).
I guess my question is, what are the consequences to adjusting the current implementation of the fasta datatype? Will users be able to pull this tool easily? (I.e. When one uploads a tool and that tools uses a different fasta definition, how does galaxy handle this?) Could this new fasta declaration potentially be adapted by galaxy? Should I just define a new mtfasta datatype special for MuTect purposes?
Let me know if you have any advice,
Marco
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: https://lists.galaxyproject.org/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/