Hi,
I think you are right John. Datatypes have many issues in that regard as
I can tell, from a few bug reports. Imho datatypes should be handled
like "Tool dependency definitions". There should be only one
"installable revsion".
But that aside, emboss datatypes are already broken. For example asn1
was added into Galaxy but it still exists in emboss_datatypes.
Moreover, howto add a proper genbank datatype with sniffer, split and
merge functions? Ideally, every datatype should have its own repository,
but that is an overhead I would like to omit ... any other ideas?
I would love to discuss that issue further, maybe a hangout with Greg
and Peter?
Thanks John for your input,
Bjoern
Am 17.07.2014 18:24, schrieb John Chilton:
Even more out of office than normal so maybe I don't have the throughput to
process this but it sounds like it won't work then. If the new types aren't
going to be loaded than we cannot evolve the datatypes with new
functionality in new repositories.
Perhaps I am missing something, but in the abstract it seems Galaxy would
have no way of knowing which types are new and which types are old in this
scenario.
Not really my business so feel free to proceed however obviously - just
letting you know that it makes me nervous. I will try to find the time to
understand how the tool shed handles data types so I can speak with less
ignorance in the future.
-John
___________________________________________________________
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/
