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.

Agreed.

>
>> 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:
  http://lists.bx.psu.edu/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Reply via email to