On Mon, Jul 15, 2013 at 7:27 PM, John Chilton <chilton(a)msi.umn.edu> 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
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.
1. 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.
2. Separate the core functionality out of the Galaxy code base
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
include building a little tool shed version of the module command -
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.