Over next couple days, I'll take a look at what's in lib/galaxy/web/base/pluginframework.py and see if there is a way to refactor it with my stuff in order to get a general plugin framework (galaxy.pluginframework) as proposed by James. Sorry for the delay. Teaching a math class this semester is really eating up my time.
Sincerely, Michael E. Cotterell
Ph.D. Student in Computer Science, University of Georgia Instructor of Record, Graduate RA & TA, University of Georgia Department Liaison, CS Graduate Student Association, University of Georgia mepcotterell@gmail.com (mailto:mepcotterell@gmail.com) mepcott@uga.edu (mailto:mepcott@uga.edu) mec@cs.uga.edu (mailto:mec@cs.uga.edu) http://michaelcotterell.com/
On Tuesday, September 3, 2013 at 12:45 PM, Carl Eberhard wrote:
It is web-specific and only handles the mako/static serving cases. I think the only areas we were generalizing at this point were the directory structures and main configuration.
Agreed on more generalization and the hook system. Michael's stuff is a good direction to move in.
I know John was looking to use it for dynamic job destinations and dynamic toolbox filters. I'd like to see some lab/community discussion on (even broad stroke) functional requirements and use cases.
On Tue, Sep 3, 2013 at 12:27 PM, James Taylor <james@jamestaylor.org (mailto:james@jamestaylor.org)> wrote:
Carl, is what you have now totally web specific? It would be great to have a general plugin framework (galaxy.pluginframework) which the web stuff could perhaps extend?
On Tue, Sep 3, 2013 at 10:56 AM, Carl Eberhard <carlfeberhard@gmail.com (mailto:carlfeberhard@gmail.com)> wrote:
Heya, Michael
Right now our only plugin code is located in lib/galaxy/web/base/pluginframework.py. It's only purpose so far is to:
- allow locally modified/created code to serve mako templates and static
pages/resources from paste.
- serve as a super class for the visualization framework.
I think your git repo has some great ideas.
Carl
On Fri, Aug 30, 2013 at 2:25 PM, Michael Cotterell <mepcotterell@gmail.com (mailto:mepcotterell@gmail.com)> wrote:
Is this plugin code hosted anywhere (like in central)?
On Monday, August 26, 2013, James Taylor wrote:
Michael,
Carl has been working on a plugin framework for Galaxy, and John Chilton has made some improvements. It would be great if you could look over what each other has done and come up with some suggestions. I personally am in favor of a very generic hook system where a hook can be defined anywhere in the code and then the user can provide any callable.
I'm fond of the way sup implemented hooks, see the use of HookManager here: https://github.com/sup-heliotrope/sup/blob/develop/lib/sup/time.rb
Your approach is quite similar and I like it.
This makes it easy to have a script that can list all available hooks with their documentation.
-- James Taylor, Assistant Professor, Biology/CS, Emory University
On Fri, Aug 23, 2013 at 10:29 AM, Michael E. Cotterell <mepcotterell@gmail.com (mailto:mepcotterell@gmail.com)> wrote:
James,
Has there been any more talk about this? I'd be willing to work in my reference implementation into central as a pull request, but I don't want to do that unless there is an agreed upon roadmap or something.
Thanks!
Sincerely, Michael E. Cotterell
Ph.D. Student in Computer Science, University of Georgia Instructor of Record, Graduate RA & TA, University of Georgia Department Liaison, CS Graduate Student Association, University of Georgia mepcotterell@gmail.com (mailto:mepcotterell@gmail.com) (mailto:mepcotterell@gmail.com) mepcott@uga.edu (mailto:mepcott@uga.edu) (mailto:mepcott@uga.edu) mec@cs.uga.edu (mailto:mec@cs.uga.edu) (mailto:mec@cs.uga.edu) http://michaelcotterell.com/
On Tuesday, July 16, 2013 at 2:08 PM, Michael E. Cotterell wrote:
> James, > > That's exactly what I was thinking. In my opinion, hooks are the way > to go (as seen in my example), but if there's a better way then I'm game for > that to. I just want to be able to extend Galaxy without modifying Galaxy > itself. > > Thanks! > > Sincerely, > Michael E. Cotterell > > Ph.D. Student in Computer Science, University of Georgia > Instructor of Record, Graduate RA & TA, University of Georgia > Faculty Liaison, CS Graduate Student Association, University of > Georgia > mepcotterell@gmail.com (mailto:mepcotterell@gmail.com) (mailto:mepcotterell@gmail.com) > mepcott@uga.edu (mailto:mepcott@uga.edu) (mailto:mepcott@uga.edu) > mec@cs.uga.edu (mailto:mec@cs.uga.edu) (mailto:mec@cs.uga.edu) > http://michaelcotterell.com/ > > > On Tuesday, July 16, 2013 at 2:05 PM, James Taylor wrote: > > > Michael, > > > > Galaxy is all about plugins! Tools, datatypes, batch systems, > > visualizations, et cetera. > > > > Additional ways to extend Galaxy through plugins are very welcome. > > We > > just need to make sure that whatever solution is chosen is extremely > > general. > > > > -- > > James Taylor, Assistant Professor, Biology/CS, Emory University > > > > > > On Tue, Jul 16, 2013 at 1:57 PM, Michael E. Cotterell > > <mepcotterell@gmail.com (mailto:mepcotterell@gmail.com) (mailto:mepcotterell@gmail.com)> wrote: > > > Are there any plans in the works to support plugins within Galaxy? > > > One of the tools I'm working on is actually more of an extension of the > > > workflow canvas/editor's user interface. Right now, I've minimized the > > > modifications required to the editor.mako file to simply adding a mako > > > include near the bottom of the file. However, like I just said, this > > > requires editing a Galaxy file. It would be a lot better if Galaxy supported > > > plugins with hooks, thus allowing me to extend the user interface (or any > > > other part of the application) by registering hooks in a plugin. > > > > > > To demonstrate how easy it would be to integrate plugins into a > > > python application, I've written up a simple plugin manager script (~100 > > > loc) an placed it in a gist: https://gist.git > > >
-- Sincerely, Michael E. Cotterell
Ph.D. Student in Computer Science, University of Georgia Graduate RA & TA, University of Georgia mepcotterell@gmail.com (mailto:mepcotterell@gmail.com) mepcott@uga.edu (mailto:mepcott@uga.edu) mec@cs.uga.edu (mailto:mec@cs.uga.edu) http://michaelcotterell.com/
Heya, Michael
I'm currently working in this area as well now - so no worries if your schedule doesn't permit.
The card is here: https://trello.com/c/c2AzV3Xf
Any feedback is appreciated.
On Mon, Sep 16, 2013 at 11:42 AM, Michael E. Cotterell < mepcotterell@gmail.com> wrote:
Over next couple days, I'll take a look at what's in lib/galaxy/web/base/pluginframework.py and see if there is a way to refactor it with my stuff in order to get a general plugin framework (galaxy.pluginframework) as proposed by James. Sorry for the delay. Teaching a math class this semester is really eating up my time.
Sincerely, Michael E. Cotterell
Ph.D. Student in Computer Science, University of Georgia Instructor of Record, Graduate RA & TA, University of Georgia Department Liaison, CS Graduate Student Association, University of Georgia mepcotterell@gmail.com (mailto:mepcotterell@gmail.com) mepcott@uga.edu (mailto:mepcott@uga.edu) mec@cs.uga.edu (mailto:mec@cs.uga.edu) http://michaelcotterell.com/
On Tuesday, September 3, 2013 at 12:45 PM, Carl Eberhard wrote:
It is web-specific and only handles the mako/static serving cases. I
think the only areas we were generalizing at this point were the directory structures and main configuration.
Agreed on more generalization and the hook system. Michael's stuff is a
good direction to move in.
I know John was looking to use it for dynamic job destinations and
dynamic toolbox filters. I'd like to see some lab/community discussion on (even broad stroke) functional requirements and use cases.
On Tue, Sep 3, 2013 at 12:27 PM, James Taylor <james@jamestaylor.org(mailto:
james@jamestaylor.org)> wrote:
Carl, is what you have now totally web specific? It would be great to have a general plugin framework (galaxy.pluginframework) which the web stuff could perhaps extend?
On Tue, Sep 3, 2013 at 10:56 AM, Carl Eberhard <
carlfeberhard@gmail.com (mailto:carlfeberhard@gmail.com)> wrote:
Heya, Michael
Right now our only plugin code is located in lib/galaxy/web/base/pluginframework.py. It's only purpose so far is
to:
- allow locally modified/created code to serve mako templates and
static
pages/resources from paste.
- serve as a super class for the visualization framework.
I think your git repo has some great ideas.
Carl
On Fri, Aug 30, 2013 at 2:25 PM, Michael Cotterell <
mepcotterell@gmail.com (mailto:mepcotterell@gmail.com)>
wrote:
Is this plugin code hosted anywhere (like in central)?
On Monday, August 26, 2013, James Taylor wrote:
Michael,
Carl has been working on a plugin framework for Galaxy, and John Chilton has made some improvements. It would be great if you
could
look over what each other has done and come up with some
suggestions.
I personally am in favor of a very generic hook system where a
hook
can be defined anywhere in the code and then the user can
provide any
callable.
I'm fond of the way sup implemented hooks, see the use of
HookManager
here:
https://github.com/sup-heliotrope/sup/blob/develop/lib/sup/time.rb
Your approach is quite similar and I like it.
This makes it easy to have a script that can list all available
hooks
with their documentation.
-- James Taylor, Assistant Professor, Biology/CS, Emory University
On Fri, Aug 23, 2013 at 10:29 AM, Michael E. Cotterell <mepcotterell@gmail.com (mailto:mepcotterell@gmail.com)> wrote: > James, > > Has there been any more talk about this? I'd be willing to
work in my
> reference implementation into central as a pull request, but I
don't want to
> do that unless there is an agreed upon roadmap or something. > > Thanks! > > Sincerely, > Michael E. Cotterell > > Ph.D. Student in Computer Science, University of Georgia > Instructor of Record, Graduate RA & TA, University of Georgia > Department Liaison, CS Graduate Student Association,
University of
> Georgia > mepcotterell@gmail.com (mailto:mepcotterell@gmail.com)
(mailto:mepcotterell@gmail.com)
> mepcott@uga.edu (mailto:mepcott@uga.edu) (mailto:
mepcott@uga.edu)
> mec@cs.uga.edu (mailto:mec@cs.uga.edu) (mailto:mec@cs.uga.edu) > http://michaelcotterell.com/ > > > On Tuesday, July 16, 2013 at 2:08 PM, Michael E. Cotterell
wrote:
> > > James, > > > > That's exactly what I was thinking. In my opinion, hooks are
the way
> > to go (as seen in my example), but if there's a better way
then I'm game for
> > that to. I just want to be able to extend Galaxy without
modifying Galaxy
> > itself. > > > > Thanks! > > > > Sincerely, > > Michael E. Cotterell > > > > Ph.D. Student in Computer Science, University of Georgia > > Instructor of Record, Graduate RA & TA, University of Georgia > > Faculty Liaison, CS Graduate Student Association, University
of
> > Georgia > > mepcotterell@gmail.com (mailto:mepcotterell@gmail.com)
(mailto:mepcotterell@gmail.com)
> > mepcott@uga.edu (mailto:mepcott@uga.edu) (mailto:
mepcott@uga.edu)
> > mec@cs.uga.edu (mailto:mec@cs.uga.edu) (mailto:
mec@cs.uga.edu)
> > http://michaelcotterell.com/ > > > > > > On Tuesday, July 16, 2013 at 2:05 PM, James Taylor wrote: > > > > > Michael, > > > > > > Galaxy is all about plugins! Tools, datatypes, batch
systems,
> > > visualizations, et cetera. > > > > > > Additional ways to extend Galaxy through plugins are very
welcome.
> > > We > > > just need to make sure that whatever solution is chosen is
extremely
> > > general. > > > > > > -- > > > James Taylor, Assistant Professor, Biology/CS, Emory
University
> > > > > > > > > On Tue, Jul 16, 2013 at 1:57 PM, Michael E. Cotterell > > > <mepcotterell@gmail.com (mailto:mepcotterell@gmail.com)
(mailto:mepcotterell@gmail.com)> wrote:
> > > > Are there any plans in the works to support plugins
within Galaxy?
> > > > One of the tools I'm working on is actually more of an
extension of the
> > > > workflow canvas/editor's user interface. Right now, I've
minimized the
> > > > modifications required to the editor.mako file to simply
adding a mako
> > > > include near the bottom of the file. However, like I
just said, this
> > > > requires editing a Galaxy file. It would be a lot better
if Galaxy supported
> > > > plugins with hooks, thus allowing me to extend the user
interface (or any
> > > > other part of the application) by registering hooks in a
plugin.
> > > > > > > > To demonstrate how easy it would be to integrate plugins
into a
> > > > python application, I've written up a simple plugin
manager script (~100
> > > > loc) an placed it in a gist: https://gist.git > > > > > >
-- Sincerely, Michael E. Cotterell
Ph.D. Student in Computer Science, University of Georgia Graduate RA & TA, University of Georgia mepcotterell@gmail.com (mailto:mepcotterell@gmail.com) mepcott@uga.edu (mailto:mepcott@uga.edu) mec@cs.uga.edu (mailto:mec@cs.uga.edu) http://michaelcotterell.com/
I've factored out the plugin discovery from the (page serving) plugin framework and subclassed an initial stab at a hook plugin manager. The page serving responsibilities are now in a separate subclass and the visualization registry is based on that: https://bitbucket.org/galaxy/galaxy-central/src/2d0bcb07596c4c688ed3908391d8...
It should at least be easier modify. Have a look and let me know if you see any issues or have suggestions.
On Tue, Sep 17, 2013 at 11:19 AM, Carl Eberhard carlfeberhard@gmail.comwrote:
Heya, Michael
I'm currently working in this area as well now - so no worries if your schedule doesn't permit.
The card is here: https://trello.com/c/c2AzV3Xf
Any feedback is appreciated.
On Mon, Sep 16, 2013 at 11:42 AM, Michael E. Cotterell < mepcotterell@gmail.com> wrote:
Over next couple days, I'll take a look at what's in lib/galaxy/web/base/pluginframework.py and see if there is a way to refactor it with my stuff in order to get a general plugin framework (galaxy.pluginframework) as proposed by James. Sorry for the delay. Teaching a math class this semester is really eating up my time.
Sincerely, Michael E. Cotterell
Ph.D. Student in Computer Science, University of Georgia Instructor of Record, Graduate RA & TA, University of Georgia Department Liaison, CS Graduate Student Association, University of Georgia mepcotterell@gmail.com (mailto:mepcotterell@gmail.com) mepcott@uga.edu (mailto:mepcott@uga.edu) mec@cs.uga.edu (mailto:mec@cs.uga.edu) http://michaelcotterell.com/
On Tuesday, September 3, 2013 at 12:45 PM, Carl Eberhard wrote:
It is web-specific and only handles the mako/static serving cases. I
think the only areas we were generalizing at this point were the directory structures and main configuration.
Agreed on more generalization and the hook system. Michael's stuff is a
good direction to move in.
I know John was looking to use it for dynamic job destinations and
dynamic toolbox filters. I'd like to see some lab/community discussion on (even broad stroke) functional requirements and use cases.
On Tue, Sep 3, 2013 at 12:27 PM, James Taylor <james@jamestaylor.org(mailto:
james@jamestaylor.org)> wrote:
Carl, is what you have now totally web specific? It would be great to have a general plugin framework (galaxy.pluginframework) which the web stuff could perhaps extend?
On Tue, Sep 3, 2013 at 10:56 AM, Carl Eberhard <
carlfeberhard@gmail.com (mailto:carlfeberhard@gmail.com)> wrote:
Heya, Michael
Right now our only plugin code is located in lib/galaxy/web/base/pluginframework.py. It's only purpose so far is
to:
- allow locally modified/created code to serve mako templates and
static
pages/resources from paste.
- serve as a super class for the visualization framework.
I think your git repo has some great ideas.
Carl
On Fri, Aug 30, 2013 at 2:25 PM, Michael Cotterell <
mepcotterell@gmail.com (mailto:mepcotterell@gmail.com)>
wrote:
Is this plugin code hosted anywhere (like in central)?
On Monday, August 26, 2013, James Taylor wrote: > > Michael, > > Carl has been working on a plugin framework for Galaxy, and John > Chilton has made some improvements. It would be great if you
could
> look over what each other has done and come up with some
suggestions.
> I personally am in favor of a very generic hook system where a
hook
> can be defined anywhere in the code and then the user can
provide any
> callable. > > I'm fond of the way sup implemented hooks, see the use of
HookManager
> here:
https://github.com/sup-heliotrope/sup/blob/develop/lib/sup/time.rb
> > Your approach is quite similar and I like it. > > This makes it easy to have a script that can list all available
hooks
> with their documentation. > > > -- > James Taylor, Assistant Professor, Biology/CS, Emory University > > > On Fri, Aug 23, 2013 at 10:29 AM, Michael E. Cotterell > <mepcotterell@gmail.com (mailto:mepcotterell@gmail.com)> wrote: > > James, > > > > Has there been any more talk about this? I'd be willing to
work in my
> > reference implementation into central as a pull request, but
I don't want to
> > do that unless there is an agreed upon roadmap or something. > > > > Thanks! > > > > Sincerely, > > Michael E. Cotterell > > > > Ph.D. Student in Computer Science, University of Georgia > > Instructor of Record, Graduate RA & TA, University of Georgia > > Department Liaison, CS Graduate Student Association,
University of
> > Georgia > > mepcotterell@gmail.com (mailto:mepcotterell@gmail.com)
(mailto:mepcotterell@gmail.com)
> > mepcott@uga.edu (mailto:mepcott@uga.edu) (mailto:
mepcott@uga.edu)
> > mec@cs.uga.edu (mailto:mec@cs.uga.edu) (mailto:mec@cs.uga.edu
)
> > http://michaelcotterell.com/ > > > > > > On Tuesday, July 16, 2013 at 2:08 PM, Michael E. Cotterell
wrote:
> > > > > James, > > > > > > That's exactly what I was thinking. In my opinion, hooks
are the way
> > > to go (as seen in my example), but if there's a better way
then I'm game for
> > > that to. I just want to be able to extend Galaxy without
modifying Galaxy
> > > itself. > > > > > > Thanks! > > > > > > Sincerely, > > > Michael E. Cotterell > > > > > > Ph.D. Student in Computer Science, University of Georgia > > > Instructor of Record, Graduate RA & TA, University of
Georgia
> > > Faculty Liaison, CS Graduate Student Association,
University of
> > > Georgia > > > mepcotterell@gmail.com (mailto:mepcotterell@gmail.com)
(mailto:mepcotterell@gmail.com)
> > > mepcott@uga.edu (mailto:mepcott@uga.edu) (mailto:
mepcott@uga.edu)
> > > mec@cs.uga.edu (mailto:mec@cs.uga.edu) (mailto:
mec@cs.uga.edu)
> > > http://michaelcotterell.com/ > > > > > > > > > On Tuesday, July 16, 2013 at 2:05 PM, James Taylor wrote: > > > > > > > Michael, > > > > > > > > Galaxy is all about plugins! Tools, datatypes, batch
systems,
> > > > visualizations, et cetera. > > > > > > > > Additional ways to extend Galaxy through plugins are very
welcome.
> > > > We > > > > just need to make sure that whatever solution is chosen
is extremely
> > > > general. > > > > > > > > -- > > > > James Taylor, Assistant Professor, Biology/CS, Emory
University
> > > > > > > > > > > > On Tue, Jul 16, 2013 at 1:57 PM, Michael E. Cotterell > > > > <mepcotterell@gmail.com (mailto:mepcotterell@gmail.com)
(mailto:mepcotterell@gmail.com)> wrote:
> > > > > Are there any plans in the works to support plugins
within Galaxy?
> > > > > One of the tools I'm working on is actually more of an
extension of the
> > > > > workflow canvas/editor's user interface. Right now,
I've minimized the
> > > > > modifications required to the editor.mako file to
simply adding a mako
> > > > > include near the bottom of the file. However, like I
just said, this
> > > > > requires editing a Galaxy file. It would be a lot
better if Galaxy supported
> > > > > plugins with hooks, thus allowing me to extend the user
interface (or any
> > > > > other part of the application) by registering hooks in
a plugin.
> > > > > > > > > > To demonstrate how easy it would be to integrate
plugins into a
> > > > > python application, I've written up a simple plugin
manager script (~100
> > > > > loc) an placed it in a gist: https://gist.git > > > > > > > > > >
-- Sincerely, Michael E. Cotterell
Ph.D. Student in Computer Science, University of Georgia Graduate RA & TA, University of Georgia mepcotterell@gmail.com (mailto:mepcotterell@gmail.com) mepcott@uga.edu (mailto:mepcott@uga.edu) mec@cs.uga.edu (mailto:mec@cs.uga.edu) http://michaelcotterell.com/
Carl,
Is there a way for a tool_shed installed tool to provide a plugin? Also, have you actually added any hooks anywhere? If so, where are they documented?
Thanks!
Sincerely, Michael E. Cotterell
Ph.D. Student in Computer Science, University of Georgia Instructor of Record, Graduate RA & TA, University of Georgia Department Liaison, CS Graduate Student Association, University of Georgia mepcotterell@gmail.com (mailto:mepcotterell@gmail.com) mepcott@uga.edu (mailto:mepcott@uga.edu) mec@cs.uga.edu (mailto:mec@cs.uga.edu) http://michaelcotterell.com/
On Wednesday, September 18, 2013 at 11:00 AM, Carl Eberhard wrote:
I've factored out the plugin discovery from the (page serving) plugin framework and subclassed an initial stab at a hook plugin manager. The page serving responsibilities are now in a separate subclass and the visualization registry is based on that: https://bitbucket.org/galaxy/galaxy-central/src/2d0bcb07596c4c688ed3908391d8...
It should at least be easier modify. Have a look and let me know if you see any issues or have suggestions.
On Tue, Sep 17, 2013 at 11:19 AM, Carl Eberhard <carlfeberhard@gmail.com (mailto:carlfeberhard@gmail.com)> wrote:
Heya, Michael
I'm currently working in this area as well now - so no worries if your schedule doesn't permit.
The card is here: https://trello.com/c/c2AzV3Xf
Any feedback is appreciated.
On Mon, Sep 16, 2013 at 11:42 AM, Michael E. Cotterell <mepcotterell@gmail.com (mailto:mepcotterell@gmail.com)> wrote:
Over next couple days, I'll take a look at what's in lib/galaxy/web/base/pluginframework.py and see if there is a way to refactor it with my stuff in order to get a general plugin framework (galaxy.pluginframework) as proposed by James. Sorry for the delay. Teaching a math class this semester is really eating up my time.
Sincerely, Michael E. Cotterell
Ph.D. Student in Computer Science, University of Georgia Instructor of Record, Graduate RA & TA, University of Georgia Department Liaison, CS Graduate Student Association, University of Georgia mepcotterell@gmail.com (mailto:mepcotterell@gmail.com) (mailto:mepcotterell@gmail.com) mepcott@uga.edu (mailto:mepcott@uga.edu) (mailto:mepcott@uga.edu) mec@cs.uga.edu (mailto:mec@cs.uga.edu) (mailto:mec@cs.uga.edu) http://michaelcotterell.com/
On Tuesday, September 3, 2013 at 12:45 PM, Carl Eberhard wrote:
It is web-specific and only handles the mako/static serving cases. I think the only areas we were generalizing at this point were the directory structures and main configuration.
Agreed on more generalization and the hook system. Michael's stuff is a good direction to move in.
I know John was looking to use it for dynamic job destinations and dynamic toolbox filters. I'd like to see some lab/community discussion on (even broad stroke) functional requirements and use cases.
On Tue, Sep 3, 2013 at 12:27 PM, James Taylor <james@jamestaylor.org (mailto:james@jamestaylor.org) (mailto:james@jamestaylor.org)> wrote:
Carl, is what you have now totally web specific? It would be great to have a general plugin framework (galaxy.pluginframework) which the web stuff could perhaps extend?
On Tue, Sep 3, 2013 at 10:56 AM, Carl Eberhard <carlfeberhard@gmail.com (mailto:carlfeberhard@gmail.com) (mailto:carlfeberhard@gmail.com)> wrote:
Heya, Michael
Right now our only plugin code is located in lib/galaxy/web/base/pluginframework.py. It's only purpose so far is to:
- allow locally modified/created code to serve mako templates and static
pages/resources from paste.
- serve as a super class for the visualization framework.
I think your git repo has some great ideas.
Carl
On Fri, Aug 30, 2013 at 2:25 PM, Michael Cotterell <mepcotterell@gmail.com (mailto:mepcotterell@gmail.com) (mailto:mepcotterell@gmail.com)> wrote: > > Is this plugin code hosted anywhere (like in central)? > > > On Monday, August 26, 2013, James Taylor wrote: > > > > Michael, > > > > Carl has been working on a plugin framework for Galaxy, and John > > Chilton has made some improvements. It would be great if you could > > look over what each other has done and come up with some suggestions. > > I personally am in favor of a very generic hook system where a hook > > can be defined anywhere in the code and then the user can provide any > > callable. > > > > I'm fond of the way sup implemented hooks, see the use of HookManager > > here: https://github.com/sup-heliotrope/sup/blob/develop/lib/sup/time.rb > > > > Your approach is quite similar and I like it. > > > > This makes it easy to have a script that can list all available hooks > > with their documentation. > > > > > > -- > > James Taylor, Assistant Professor, Biology/CS, Emory University > > > > > > On Fri, Aug 23, 2013 at 10:29 AM, Michael E. Cotterell > > <mepcotterell@gmail.com (mailto:mepcotterell@gmail.com) (mailto:mepcotterell@gmail.com)> wrote: > > > James, > > > > > > Has there been any more talk about this? I'd be willing to work in my > > > reference implementation into central as a pull request, but I don't want to > > > do that unless there is an agreed upon roadmap or something. > > > > > > Thanks! > > > > > > Sincerely, > > > Michael E. Cotterell > > > > > > Ph.D. Student in Computer Science, University of Georgia > > > Instructor of Record, Graduate RA & TA, University of Georgia > > > Department Liaison, CS Graduate Student Association, University of > > > Georgia > > > mepcotterell@gmail.com (mailto:mepcotterell@gmail.com) (mailto:mepcotterell@gmail.com) (mailto:mepcotterell@gmail.com) > > > mepcott@uga.edu (mailto:mepcott@uga.edu) (mailto:mepcott@uga.edu) (mailto:mepcott@uga.edu) > > > mec@cs.uga.edu (mailto:mec@cs.uga.edu) (mailto:mec@cs.uga.edu) (mailto:mec@cs.uga.edu) > > > http://michaelcotterell.com/ > > > > > > > > > On Tuesday, July 16, 2013 at 2:08 PM, Michael E. Cotterell wrote: > > > > > > > James, > > > > > > > > That's exactly what I was thinking. In my opinion, hooks are the way > > > > to go (as seen in my example), but if there's a better way then I'm game for > > > > that to. I just want to be able to extend Galaxy without modifying Galaxy > > > > itself. > > > > > > > > Thanks! > > > > > > > > Sincerely, > > > > Michael E. Cotterell > > > > > > > > Ph.D. Student in Computer Science, University of Georgia > > > > Instructor of Record, Graduate RA & TA, University of Georgia > > > > Faculty Liaison, CS Graduate Student Association, University of > > > > Georgia > > > > mepcotterell@gmail.com (mailto:mepcotterell@gmail.com) (mailto:mepcotterell@gmail.com) (mailto:mepcotterell@gmail.com) > > > > mepcott@uga.edu (mailto:mepcott@uga.edu) (mailto:mepcott@uga.edu) (mailto:mepcott@uga.edu) > > > > mec@cs.uga.edu (mailto:mec@cs.uga.edu) (mailto:mec@cs.uga.edu) (mailto:mec@cs.uga.edu) > > > > http://michaelcotterell.com/ > > > > > > > > > > > > On Tuesday, July 16, 2013 at 2:05 PM, James Taylor wrote: > > > > > > > > > Michael, > > > > > > > > > > Galaxy is all about plugins! Tools, datatypes, batch systems, > > > > > visualizations, et cetera. > > > > > > > > > > Additional ways to extend Galaxy through plugins are very welcome. > > > > > We > > > > > just need to make sure that whatever solution is chosen is extremely > > > > > general. > > > > > > > > > > -- > > > > > James Taylor, Assistant Professor, Biology/CS, Emory University > > > > > > > > > > > > > > > On Tue, Jul 16, 2013 at 1:57 PM, Michael E. Cotterell > > > > > <mepcotterell@gmail.com (mailto:mepcotterell@gmail.com) (mailto:mepcotterell@gmail.com) (mailto:mepcotterell@gmail.com)> wrote: > > > > > > Are there any plans in the works to support plugins within Galaxy? > > > > > > One of the tools I'm working on is actually more of an extension of the > > > > > > workflow canvas/editor's user interface. Right now, I've minimized the > > > > > > modifications required to the editor.mako file to simply adding a mako > > > > > > include near the bottom of the file. However, like I just said, this > > > > > > requires editing a Galaxy file. It would be a lot better if Galaxy supported > > > > > > plugins with hooks, thus allowing me to extend the user interface (or any > > > > > > other part of the application) by registering hooks in a plugin. > > > > > > > > > > > > To demonstrate how easy it would be to integrate plugins into a > > > > > > python application, I've written up a simple plugin manager script (~100 > > > > > > loc) an placed it in a gist: https://gist.git > > > > > > > > > > > > > > > > > > > > -- > Sincerely, > Michael E. Cotterell > > Ph.D. Student in Computer Science, University of Georgia > Graduate RA & TA, University of Georgia > mepcotterell@gmail.com (mailto:mepcotterell@gmail.com) (mailto:mepcotterell@gmail.com) > mepcott@uga.edu (mailto:mepcott@uga.edu) (mailto:mepcott@uga.edu) > mec@cs.uga.edu (mailto:mec@cs.uga.edu) (mailto:mec@cs.uga.edu) > http://michaelcotterell.com/
Hi, Michael
It was good meeting you in Athens. You guys are doing amazing things.
There currently is no mechanism to install a plugin (either hook or visualization) from the toolshed. I think it's certainly possible (and planned) in the future.
I haven't added any hooks for plugins. I would hope there would be some discussion as to the which places in the code would be the most useful and desired within the community. Hopefully, that discussion can be sparked soon.
As to the whether we can implement an admin link to reload the entire tool shed without restarting Galaxy: I talked a bit to Greg about it and it might be more possible and easier to reload entire tool sections (for example, 'Data sources'). Would that work for your use case?
Carl
On Thu, Mar 6, 2014 at 9:00 AM, Michael E. Cotterell <mepcotterell@gmail.com
wrote:
Carl,
Is there a way for a tool_shed installed tool to provide a plugin? Also, have you actually added any hooks anywhere? If so, where are they documented?
Thanks!
Sincerely, Michael E. Cotterell
Ph.D. Student in Computer Science, University of Georgia Instructor of Record, Graduate RA & TA, University of Georgia Department Liaison, CS Graduate Student Association, University of Georgia mepcotterell@gmail.com (mailto:mepcotterell@gmail.com) mepcott@uga.edu (mailto:mepcott@uga.edu) mec@cs.uga.edu (mailto:mec@cs.uga.edu) http://michaelcotterell.com/
On Wednesday, September 18, 2013 at 11:00 AM, Carl Eberhard wrote:
I've factored out the plugin discovery from the (page serving) plugin
framework and subclassed an initial stab at a hook plugin manager. The page serving responsibilities are now in a separate subclass and the visualization registry is based on that:
https://bitbucket.org/galaxy/galaxy-central/src/2d0bcb07596c4c688ed3908391d8...
It should at least be easier modify. Have a look and let me know if you
see any issues or have suggestions.
On Tue, Sep 17, 2013 at 11:19 AM, Carl Eberhard <carlfeberhard@gmail.com(mailto:
carlfeberhard@gmail.com)> wrote:
Heya, Michael
I'm currently working in this area as well now - so no worries if your
schedule doesn't permit.
The card is here: https://trello.com/c/c2AzV3Xf
Any feedback is appreciated.
On Mon, Sep 16, 2013 at 11:42 AM, Michael E. Cotterell <
mepcotterell@gmail.com (mailto:mepcotterell@gmail.com)> wrote:
Over next couple days, I'll take a look at what's in lib/galaxy/web/base/pluginframework.py and see if there is a way to
refactor it with my stuff in order to get a general plugin framework (galaxy.pluginframework) as proposed by James. Sorry for the delay. Teaching a math class this semester is really eating up my time.
Sincerely, Michael E. Cotterell
Ph.D. Student in Computer Science, University of Georgia Instructor of Record, Graduate RA & TA, University of Georgia Department Liaison, CS Graduate Student Association, University of
Georgia
mepcotterell@gmail.com (mailto:mepcotterell@gmail.com) (mailto:
mepcotterell@gmail.com)
mepcott@uga.edu (mailto:mepcott@uga.edu) (mailto:mepcott@uga.edu) mec@cs.uga.edu (mailto:mec@cs.uga.edu) (mailto:mec@cs.uga.edu) http://michaelcotterell.com/
On Tuesday, September 3, 2013 at 12:45 PM, Carl Eberhard wrote:
It is web-specific and only handles the mako/static serving cases.
I think the only areas we were generalizing at this point were the directory structures and main configuration.
Agreed on more generalization and the hook system. Michael's stuff
is a good direction to move in.
I know John was looking to use it for dynamic job destinations and
dynamic toolbox filters. I'd like to see some lab/community discussion on (even broad stroke) functional requirements and use cases.
On Tue, Sep 3, 2013 at 12:27 PM, James Taylor <
james@jamestaylor.org (mailto:james@jamestaylor.org) (mailto: james@jamestaylor.org)> wrote:
Carl, is what you have now totally web specific? It would be
great to
have a general plugin framework (galaxy.pluginframework) which
the web
stuff could perhaps extend?
On Tue, Sep 3, 2013 at 10:56 AM, Carl Eberhard <
carlfeberhard@gmail.com (mailto:carlfeberhard@gmail.com) (mailto: carlfeberhard@gmail.com)> wrote:
> Heya, Michael > > Right now our only plugin code is located in > lib/galaxy/web/base/pluginframework.py. It's only purpose so
far is to:
> - allow locally modified/created code to serve mako templates
and static
> pages/resources from paste. > - serve as a super class for the visualization framework. > > I think your git repo has some great ideas. > > Carl > > > On Fri, Aug 30, 2013 at 2:25 PM, Michael Cotterell <
mepcotterell@gmail.com (mailto:mepcotterell@gmail.com) (mailto: mepcotterell@gmail.com)>
> wrote: > > > > Is this plugin code hosted anywhere (like in central)? > > > > > > On Monday, August 26, 2013, James Taylor wrote: > > > > > > Michael, > > > > > > Carl has been working on a plugin framework for Galaxy,
and John
> > > Chilton has made some improvements. It would be great if
you could
> > > look over what each other has done and come up with some
suggestions.
> > > I personally am in favor of a very generic hook system
where a hook
> > > can be defined anywhere in the code and then the user can
provide any
> > > callable. > > > > > > I'm fond of the way sup implemented hooks, see the use of
HookManager
> > > here:
https://github.com/sup-heliotrope/sup/blob/develop/lib/sup/time.rb
> > > > > > Your approach is quite similar and I like it. > > > > > > This makes it easy to have a script that can list all
available hooks
> > > with their documentation. > > > > > > > > > -- > > > James Taylor, Assistant Professor, Biology/CS, Emory
University
> > > > > > > > > On Fri, Aug 23, 2013 at 10:29 AM, Michael E. Cotterell > > > <mepcotterell@gmail.com (mailto:mepcotterell@gmail.com)
(mailto:mepcotterell@gmail.com)> wrote:
> > > > James, > > > > > > > > Has there been any more talk about this? I'd be willing
to work in my
> > > > reference implementation into central as a pull request,
but I don't want to
> > > > do that unless there is an agreed upon roadmap or
something.
> > > > > > > > Thanks! > > > > > > > > Sincerely, > > > > Michael E. Cotterell > > > > > > > > Ph.D. Student in Computer Science, University of Georgia > > > > Instructor of Record, Graduate RA & TA, University of
Georgia
> > > > Department Liaison, CS Graduate Student Association,
University of
> > > > Georgia > > > > mepcotterell@gmail.com (mailto:mepcotterell@gmail.com)
(mailto:mepcotterell@gmail.com) (mailto:mepcotterell@gmail.com)
> > > > mepcott@uga.edu (mailto:mepcott@uga.edu) (mailto:
mepcott@uga.edu) (mailto:mepcott@uga.edu)
> > > > mec@cs.uga.edu (mailto:mec@cs.uga.edu) (mailto:
mec@cs.uga.edu) (mailto:mec@cs.uga.edu)
> > > > http://michaelcotterell.com/ > > > > > > > > > > > > On Tuesday, July 16, 2013 at 2:08 PM, Michael E.
Cotterell wrote:
> > > > > > > > > James, > > > > > > > > > > That's exactly what I was thinking. In my opinion,
hooks are the way
> > > > > to go (as seen in my example), but if there's a better
way then I'm game for
> > > > > that to. I just want to be able to extend Galaxy
without modifying Galaxy
> > > > > itself. > > > > > > > > > > Thanks! > > > > > > > > > > Sincerely, > > > > > Michael E. Cotterell > > > > > > > > > > Ph.D. Student in Computer Science, University of
Georgia
> > > > > Instructor of Record, Graduate RA & TA, University of
Georgia
> > > > > Faculty Liaison, CS Graduate Student Association,
University of
> > > > > Georgia > > > > > mepcotterell@gmail.com (mailto:mepcotterell@gmail.com)
(mailto:mepcotterell@gmail.com) (mailto:mepcotterell@gmail.com)
> > > > > mepcott@uga.edu (mailto:mepcott@uga.edu) (mailto:
mepcott@uga.edu) (mailto:mepcott@uga.edu)
> > > > > mec@cs.uga.edu (mailto:mec@cs.uga.edu) (mailto:
mec@cs.uga.edu) (mailto:mec@cs.uga.edu)
> > > > > http://michaelcotterell.com/ > > > > > > > > > > > > > > > On Tuesday, July 16, 2013 at 2:05 PM, James Taylor
wrote:
> > > > > > > > > > > Michael, > > > > > > > > > > > > Galaxy is all about plugins! Tools, datatypes, batch
systems,
> > > > > > visualizations, et cetera. > > > > > > > > > > > > Additional ways to extend Galaxy through plugins are
very welcome.
> > > > > > We > > > > > > just need to make sure that whatever solution is
chosen is extremely
> > > > > > general. > > > > > > > > > > > > -- > > > > > > James Taylor, Assistant Professor, Biology/CS, Emory
University
> > > > > > > > > > > > > > > > > > On Tue, Jul 16, 2013 at 1:57 PM, Michael E. Cotterell > > > > > > <mepcotterell@gmail.com (mailto:
mepcotterell@gmail.com) (mailto:mepcotterell@gmail.com) (mailto: mepcotterell@gmail.com)> wrote:
> > > > > > > Are there any plans in the works to support
plugins within Galaxy?
> > > > > > > One of the tools I'm working on is actually more
of an extension of the
> > > > > > > workflow canvas/editor's user interface. Right
now, I've minimized the
> > > > > > > modifications required to the editor.mako file to
simply adding a mako
> > > > > > > include near the bottom of the file. However, like
I just said, this
> > > > > > > requires editing a Galaxy file. It would be a lot
better if Galaxy supported
> > > > > > > plugins with hooks, thus allowing me to extend the
user interface (or any
> > > > > > > other part of the application) by registering
hooks in a plugin.
> > > > > > > > > > > > > > To demonstrate how easy it would be to integrate
plugins into a
> > > > > > > python application, I've written up a simple
plugin manager script (~100
> > > > > > > loc) an placed it in a gist: https://gist.git > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Sincerely, > > Michael E. Cotterell > > > > Ph.D. Student in Computer Science, University of Georgia > > Graduate RA & TA, University of Georgia > > mepcotterell@gmail.com (mailto:mepcotterell@gmail.com)
(mailto:mepcotterell@gmail.com)
> > mepcott@uga.edu (mailto:mepcott@uga.edu) (mailto:
mepcott@uga.edu)
> > mec@cs.uga.edu (mailto:mec@cs.uga.edu) (mailto:
mec@cs.uga.edu)
galaxy-dev@lists.galaxyproject.org
-
Carl Eberhard -
Michael E. Cotterell