Adding a New Data Type
This specification describes the Galaxy source code changes required to add support for a new data type.
Every Galaxy dataset is associated with a datatype which can be determined by the file extension (or format in the history item). Within Galaxy, supported datatypes are contained in the galaxy.datatypes.registry:Registry class, which has the responsibility of mapping extensions to datatype instances. At start up this registry is initialized with data type values from the datatypes_conf.xml file. All data type classes are a subclass of the galaxy.datatypes.data:Data class.
We'll pretend to add a new datatype format named "Foobar" whose associated file extension is "foo" to our local Galaxy instance as a way to provide the details for adding support for new data types. Our example Foobar data type will be a subclass of galaxy.datatypes.tabular.Tabular.
We'll add the new data type to the <registration> tag section of the datatypes_conf.xml file. Sample <datatype> tag attributes in this section are:
<datatype extension="ab1" type="galaxy.datatypes.images:Ab1" mimetype="application/octet-stream" display_in_upload="true"/>
extension - the data type's Dataset file extension ( e.g., ab1, bed, gff, qual, etc ) type - the path to the class for that data type mimetype - if present (it's optional), the data type's mime type display_in_upload - if present ( it's optional and defaults to False ), the associated file extension will be displayed in the "File Format" select list in the "Upload File from your computer" tool in the "Get Data" tool section of the tool panel.
1 <datatypes> 2 <registration converters_path="lib/galaxy/datatypes/converters"> 3 <datatype extension="ab1" type="galaxy.datatypes.images:Ab1" mimetype="application/octet-stream" display_in_upload="true"/> 4 <datatype extension="foo" type="galaxy.datatypes.tabular:Foobar" display_in_upload="true"/> 5 ...
Note: If you do not wish to add extended functionality to for a new datatype, but simply want to restrict the output of a set of tools to be used in another set of tools, you can add the flag subclass="True" to the datatype definition line. Example:
1 <datatype extension="my_tabular_subclass" type="galaxy.datatypes.tabular:Tabular" subclass="True"/>
Galaxy tools are configured to automatically set the data type of an output dataset. However, in some scenarios, Galaxy will attempt to determine the data type of a file using a sniffer (e.g., uploading a file from a local disk with 'Auto-detect' selected in the File Format select list). The order in which Galaxy attempts to determine data types is critical because some formats are much more loosely defined than others. The order in which the sniffer for each data type is applied to the file should be most rigidly defined formats first followed by less and less rigidly defined formats, with the most loosely defined format last, and then a default format associated with the file if none of the data type sniffers were successful. The order in which data type sniffers are applied to files is implicit in the <sniffers> tag set section of the datatypes_conf.xml file. We'll assume that the format of our Foobar data type is fairly rigidly defined, so it can be placed closer to the start of the sniff order.
We'll now create a new code file, galaxy.datatypes.foobar.py, that will contain the Foobar class (in this example we could simply add the Foobar class to the galaxy.datatypes.tabular.py code file). Keep in mind that your new data type class should be placed in a file that is appropriate (based on it's superclass), and that the file will need to be imported by lib/galaxy/datatypes/registry.py. You will need to include a file_ext attribute to your class and create any necessary functions to override the functions in your new data type's superclass (in our example, the galaxy.datatypes.tabular.Tabular class). In our example below, we have set our class's file_ext attribute to "foo" and we have overridden the __init__(), init_meta() and sniff() functions. It is important to override functions (especially the meta data and sniff functions) if the attributes of your new class differ from those of it's superclass. Note: sniff functions are not required to be included in new data type classes, but if the sniff function is missing, Galaxy will end up associating the default data type and file extension (Text and 'txt' in our example) with the file. For binary files, the default would be Data and 'data'.
1 from galaxy import eggs 2 3 import pkg_resources 4 pkg_resources.require( "bx-python" ) 5 6 import logging, os, sys, time, sets, tempfile, shutil 7 import data 8 from galaxy import util 9 from galaxy.datatypes.sniff import * 10 from cgi import escape 11 import urllib 12 from bx.intervals.io import * 13 from galaxy.datatypes import metadata 14 from galaxy.datatypes.metadata import MetadataElement 15 from galaxy.datatypes.tabular import Tabular 16 17 class Foobar( Tabular ): 18 """Tab delimited data in foo format""" 19 file_ext = "foo" 20 21 MetadataElement( name="columns", default=3, desc="Number of columns", readonly=True ) 22 23 def __init__(self, **kwd): 24 """Initialize foobar datatype""" 25 Tabular.__init__(self, **kwd) 26 self.do_something_else() 27 28 def init_meta( self, dataset, copy_from=None ): 29 Tabular.init_meta( self, dataset, copy_from=copy_from ) 30 if elems_len == 8: 31 try: 32 map( int, [hdr, hdr] ) 33 proceed = True 34 except: 35 pass 36 37 def sniff( self, filename ): 38 headers = get_headers( filename, '\t' ) 39 try: 40 if len(headers) < 2: 41 return False 42 for hdr in headers: 43 if len( hdr ) > 1 and hdr and not hdr.startswith( '#' ): 44 if len(hdr) != 8: 45 return False 46 try: 47 map( int, [hdr, hdr] ) 48 except: 49 return False 50 # Do other necessary checking here... 51 except: 52 return False 53 # If we haven't yet returned False, then... 54 return True 55 56 ...
That should be it! If all of your code is functionally correct you should now have support for your new data type within your Galaxy instance.