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>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> 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.
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
> 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
> > > 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
On Tue, Sep 3, 2013 at 12:27 PM, James Taylor <james@jamestaylor.org(mailto: james@jamestaylor.org)> wrote: provide any then I'm game for 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/