On Mon, Jul 15, 2013 at 7:27 PM, John Chilton email@example.com wrote:
One of my goals for the GCC was to sell the idea that tool shed repositories need to be installable without a database present. I
John, as I've mentioned in the past I'm very strongly in favor of this. There is absolutely no reason why the ToolShed needs to be tied to Galaxy. For dependency installation we've now got a nice system that does version isolation well, and I've had several groups express interest in using the wrappers from the ToolShed in environments other than Galaxy.
from Greg and others (Dave, Bjorn, Peter, Nate) has gone into building a modular dependency system that could very easily be leveraged by applications other than Galaxy, so the extra steps that could be taken to make this possible should to make the codebase as broadly useful and to encourage adoption.
- Rework installing tool shed repositories to not require a database. A kind
of messy way to do this might be adding a use_database flag throughout. A cleaner way might be to use allow the core functionality to work with callbacks or plugins that performed the database interactions.
Personally I would definitely prefer a plugin model. Basically, a layer isolating the underlying datastore used during tool installation, dependency resolution, et cetera. However, it occurs to me that even if the tool installation component is isolation from Galaxy, it could still use the same model and database. All package management systems need some way to maintain state, a sqlite database is not an unreasonable choice.
- Separate the core functionality out of the Galaxy code base entirely into
a reusable, stand-alone library.
This is a long term goal for us. I think at first we'd like to at least see it all happen in the same repository so that we can still support a checkout and run scenario. But decoupling the various web applications and share components that make up the Galaxy ecosystem is very important.
include building a little tool shed version of the module command - http://linux.die.net/man/1/module to demonstrate this work and have something immediately useful produced.
YES! Absolutely. One of the reasons for the way tool dependency injection was implemented was to support a command line module system. Coupling this with the toolshed to also enable dependency installation and management completes the puzzle.
(and yes to all the various commands, through I figured it would be gx_module ;)
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.