> 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

I'd definitely like to hear more about this.

Michael E. Cotterell

Ph.D. Student in Computer Science, University of Georgia
Graduate RA & TA, University of Georgia
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:

Reply via email to