> This would be different from using the API scripts because there would be > no > API, Galaxy instance, or Galaxy database involved - just the Galaxy code. > If > this was able to split into its own Python library, one could imagine even > allowing something like tsmodule to be installable right from pip and > recursively fetch a toolshed_client library or something like that. >
I especially like this idea. I wasn't at GCC, but my boss was, so you may have seen some of the stuff I'm working on with Web Services. Right now, the transition to the tool shed it awesome, except for when it comes time to actually run the tools for adding web services. You see right now, the tool my colleagues and I have developed dynamically creates tool config files based on WSDLs and WADLs. The problem is, at the moment, our tool actually edits the tools_config.xml file directly in order to add the web service operation tools to galaxy. Your idea, if I understand it correctly, would mean that it might be possible for my tool to utilize this other method of installation in order to add/remove the generated tools to Galaxy. I'd definitely like to hear more about this. -- Sincerely, Michael E. Cotterell Ph.D. Student in Computer Science, University of Georgia Graduate RA & TA, University of Georgia mepcotter...@gmail.com mepc...@uga.edu m...@cs.uga.edu http://michaelcotterell.com/
___________________________________________________________ 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/
