On Mon, Jul 15, 2013 at 7:27 PM, John Chilton <chil...@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
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.


>   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 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.

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