Tool development without a local Tool Shed?
Dear all, Until recently I'd not needed to define new datatypes while developing tools for Galaxy - instead using (and sometimes modifying) existing datatypes in situ. I have been manually 'installing' my in-development tools by added their XML files to tool_conf.xml - and this has worked fine to date. However, I would now like to experiment with defining or modifying datatypes which would eventually be defined via a datatypes_conf.xml file in a ToolShed entry. My impression from reading the latest wiki documentation on http://wiki.g2.bx.psu.edu/Tool%20Shed is that I will have to install my own local tool shed. Is there a simpler alternative? e.g. Can I add the new datatypes_conf.xml file(s) to a configuration entry instead? Thanks, Peter
Hi Peter, I assume you are using a Galaxy instance within your development environment when developing new Galaxy tools so that you ultimately ensure your tool is functionally correct. Adding a local tool shed to your development environment will help you ensure that certain tool shed related processes (e.g., setting tool shed metadata, installing the repository into a local Galaxy, etc) are functionally correct. With regard to proprietary datatypes (these are datatypes that are included in a tool shed repository), the process is simple if the datatypes are all subclassed from datatypes defined in the Galaxy framework. The emboss_datatypes are an example of this category, where the "type" attribute is something like "galaxy.datatypes.data:Text". You probably don't need to use a local tool shed to help in the development of tools that use this kind of proprietary datatype. The more complex category is when the proprietary datatypes subclass from proprietary classes defined in a code file in the repository. In this case, the class file's import statement definitions must be fully qualified. This is the category where using a local tool shed as a component of the development process may be beneficial as you can ensure the proprietary datatypes class file is written in such a way that the installation process into a local Galaxy instance is functionally correct. There is currently no way to define proprietary datatypes_conf.xml files in a configuration entry. Sorry for the long-winded answer - hopefully the context is helpful. Greg Von Kuster On Aug 23, 2012, at 10:11 AM, Peter Cock wrote:
Dear all,
Until recently I'd not needed to define new datatypes while developing tools for Galaxy - instead using (and sometimes modifying) existing datatypes in situ. I have been manually 'installing' my in-development tools by added their XML files to tool_conf.xml - and this has worked fine to date.
However, I would now like to experiment with defining or modifying datatypes which would eventually be defined via a datatypes_conf.xml file in a ToolShed entry.
My impression from reading the latest wiki documentation on http://wiki.g2.bx.psu.edu/Tool%20Shed is that I will have to install my own local tool shed.
Is there a simpler alternative? e.g. Can I add the new datatypes_conf.xml file(s) to a configuration entry instead?
Thanks,
Peter ___________________________________________________________ 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:
On Mon, Aug 27, 2012 at 1:58 PM, Greg Von Kuster <greg@bx.psu.edu> wrote:
Hi Peter,
I assume you are using a Galaxy instance within your development environment when developing new Galaxy tools so that you ultimately ensure your tool is functionally correct. Adding a local tool shed to your development environment will help you ensure that certain tool shed related processes (e.g., setting tool shed metadata, installing the repository into a local Galaxy, etc) are functionally correct.
With regard to proprietary datatypes (these are datatypes that are included in a tool shed repository), the process is simple if the datatypes are all subclassed from datatypes defined in the Galaxy framework. The emboss_datatypes are an example of this category, where the "type" attribute is something like "galaxy.datatypes.data:Text". You probably don't need to use a local tool shed to help in the development of tools that use this kind of proprietary datatype.
The more complex category is when the proprietary datatypes subclass from proprietary classes defined in a code file in the repository. In this case, the class file's import statement definitions must be fully qualified. This is the category where using a local tool shed as a component of the development process may be beneficial as you can ensure the proprietary datatypes class file is written in such a way that the installation process into a local Galaxy instance is functionally correct.
There is currently no way to define proprietary datatypes_conf.xml files in a configuration entry.
Sorry for the long-winded answer - hopefully the context is helpful.
Greg Von Kuster
That is helpful Greg - thank you - although I worry the learning curve for developing Galaxy tools is getting steeper. You've implied 'simple' proprietary datatypes which depend only on Galaxy itself (and not other ToolShed entries) can be developed without a local ToolShed. That's the situation I'm interested in. How would I enable the 'blastxml' datatype (now in the ToolShed as 'blast_datatypes')? My guess is adding something to file datatypes_conf.xml, which used to include these lines: <datatype extension="blastxml" type="galaxy.datatypes.xml:BlastXml" mimetype="application/xml" display_in_upload="true"/> and: <sniffer type="galaxy.datatypes.xml:BlastXml"/> Thanks, Peter
If you install the blast_datatypes repository into your Galaxy instance using the tool shed installation process everything necessary is handled for you automatically, but I understand you are not yet installing from the tool shed. If you are not installing, you'll have to manually download the repository contents from the tool shed using the "Repository Actions" pop-up menu and place the contained xml.py file in the appropriate location so it can be loaded when you start your Galaxy server. You'll then need to manually add the datatype entries in your datatypes_conf.xml file as they used to be. Greg On Aug 27, 2012, at 9:39 AM, Peter Cock wrote:
That is helpful Greg - thank you - although I worry the learning curve for developing Galaxy tools is getting steeper.
You've implied 'simple' proprietary datatypes which depend only on Galaxy itself (and not other ToolShed entries) can be developed without a local ToolShed. That's the situation I'm interested in.
How would I enable the 'blastxml' datatype (now in the ToolShed as 'blast_datatypes')? My guess is adding something to file datatypes_conf.xml, which used to include these lines:
<datatype extension="blastxml" type="galaxy.datatypes.xml:BlastXml" mimetype="application/xml" display_in_upload="true"/>
and:
<sniffer type="galaxy.datatypes.xml:BlastXml"/>
Thanks,
Peter
On Mon, Aug 27, 2012 at 3:31 PM, Greg Von Kuster <greg@bx.psu.edu> wrote:
If you install the blast_datatypes repository into your Galaxy instance using the tool shed installation process everything necessary is handled for you automatically, but I understand you are not yet installing from the tool shed.
Exactly.
If you are not installing, you'll have to manually download the repository contents from the tool shed using the "Repository Actions" pop-up menu and place the contained xml.py file in the appropriate location so it can be loaded when you start your Galaxy server. You'll then need to manually add the datatype entries in your datatypes_conf.xml file as they used to be.
Assuming by proper place you mean under the Galaxy folder lib/galaxy/datatypes/ then that makes sense - thanks. In this particular case there would be a name clash with xml.py, since there is still a file of that name in the main repository to define the XML base class etc. That isn't critical as I can rename the ToolShed file to blast.py (or similar), which would make sense anyway as I want to include additional formats for BLAST databases. Thanks, Peter
participants (2)
-
Greg Von Kuster -
Peter Cock