On Tue, Jul 16, 2013 at 1:16 PM, James Taylor <ja...@jamestaylor.org> wrote:
> 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.
> Exactly!
>>   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.

An sqlite database wasn't what I was imaging, but it seems thoroughly
reasonable and the cleanest thing to implement.

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