Am 17.07.2014 18:51, schrieb Peter Cock:
On Thu, Jul 17, 2014 at 5:45 PM, Björn Grüning
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
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
Thanks John for your input,
This could be high level, e.g. "other sequence file formats" repository
covering GenBank, EMBL, SwissProt plain text, UniProt XML, etc;
one for multiple sequence alignments; one for EMBOSS' own output...
That was my initial idea. Starting point is here:
But it wouldn't be that much more work to do one ToolShed repo
per additional file format, would it?
Uploading and creating descriptions in the toolshed will take most of
the time :)
Lets see if I can use a train trip to do that ... but the problem will
stay the same ... one repository can have multiple versions ...
One reason I have been meaning to do some of these is familiarity with
many of these formats from looking after/writing parsers in Biopython.
Having this done sooner rather than later ought to head off too many
incompatible datatype names which worries me. Is it too late to adopt
something like the EDAM ontology for the datatypes within Galaxy?
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:
To search Galaxy mailing lists use the unified search at: