On Mon, Aug 27, 2012 at 1:58 PM, Greg Von Kuster <g...@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 ___________________________________________________________ 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/
