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
mepcotterell@gmail.com
mepcott@uga.edu
mec@cs.uga.edu
http://michaelcotterell.com/