Fasta Datatype Adjustments

classic Classic list List threaded Threaded
2 messages Options
| Threaded
Open this post in threaded view
|

Fasta Datatype Adjustments

marcoalbuquerque
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/
| Threaded
Open this post in threaded view
|

Re: Fasta Datatype Adjustments

John Chilton-4
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
<[hidden email]> 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/
___________________________________________________________
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/