Plugin system question...

1 view
Skip to first unread message

Adam Jones

unread,
Jan 27, 2007, 11:23:14 PM1/27/07
to TurboGears Trunk
I am a big fan of setuptools. It is an awesome piece of software, and
one that TurboGears seems to only partially leverage. Case in point,
plugins. SetupTools makes these pretty easy through the use of
entry_points, which are already in use to provide extensions to tg-
admin, alternative identity providers, and a few other useful things.

It seems like there are other places where this is not used, but could
be, and I would like to ask why. The impetus for this was in the Visit
system, where new plugins are registered by passing an initialized
object to 'turbogears.visit.enable_visit_plugin', and calling that
from a function appended to 'turbogears.startup.call_on_startup'. If
this were switched to an entry point (say, 'turbogears.visit.plugin')
it would be a simple matter of configuration to make this happen. It
seems really odd to me to have these two methods of handling basically
the same thing. I think that, barring any important technical barries,
it would make more sense to have any plugins handled through one
system.

Obviously that would be a breaking change, so it should be handled
carefully, but I think in the end it would be more useful. Thoughts,
questions, declarations of unmitigated stupidity?

-Adam

Alberto Valverde

unread,
Jan 28, 2007, 8:34:39 AM1/28/07
to turbogea...@googlegroups.com

On Jan 28, 2007, at 5:23 AM, Adam Jones wrote:

>
> I am a big fan of setuptools. It is an awesome piece of software, and
> one that TurboGears seems to only partially leverage. Case in point,
> plugins. SetupTools makes these pretty easy through the use of
> entry_points, which are already in use to provide extensions to tg-
> admin, alternative identity providers, and a few other useful things.
>
> It seems like there are other places where this is not used, but could
> be, and I would like to ask why. The impetus for this was in the Visit
> system, where new plugins are registered by passing an initialized
> object to 'turbogears.visit.enable_visit_plugin', and calling that
> from a function appended to 'turbogears.startup.call_on_startup'. If
> this were switched to an entry point (say, 'turbogears.visit.plugin')
> it would be a simple matter of configuration to make this happen. It
> seems really odd to me to have these two methods of handling basically
> the same thing. I think that, barring any important technical barries,
> it would make more sense to have any plugins handled through one
> system.

That's a good idea. Now we have tg.util.load_class to load the
identity/visit classses as defined by the configuration file. This
could be changed to use pkg_resources.EntryPoint.parse which does
something similar but in a more robust way and would open the door to
define the classes in the configuration file using uris similar to
paste deploy's.:

visit_class = egg:MyVisitPlugins#sa_visit
user_class = myapp.models:AppUser

That would load a visit_class from the MyVisitPlugins egg entry_point
named "sa_visit" and a user class from myapp.models called AppUser.
Both ways of loading the objects (ep from egg and explicit module
path) would go through setuptools.

paste.deploy has code for parsing and loading plugins using the
"egg:" protocol that we could use... it's just a matter of
integrating it with identity :)

Identity is going to be refactored out into separate middleware
components for TG 2.0 (visit, authorization and authentication) but
moving to setuptools for loading plugins could be done in 1.1 *if it
adheres to the current API as much as possible*. If anyone wants to
take a shot at it the trunk is open :)

Alberto

Adam Jones

unread,
Jan 28, 2007, 1:28:09 PM1/28/07
to TurboGears Trunk

On Jan 28, 5:34 am, Alberto Valverde <albe...@toscat.net> wrote:
> That's a good idea. Now we have tg.util.load_class to load the
> identity/visit classses as defined by the configuration file. This
> could be changed to use pkg_resources.EntryPoint.parse which does
> something similar but in a more robust way and would open the door to
> define the classes in the configuration file using uris similar to
> paste deploy's.:
>
> visit_class = egg:MyVisitPlugins#sa_visit
> user_class = myapp.models:AppUser
>
> That would load a visit_class from the MyVisitPlugins egg entry_point
> named "sa_visit" and a user class from myapp.models called AppUser.
> Both ways of loading the objects (ep from egg and explicit module
> path) would go through setuptools.
>
> paste.deploy has code for parsing and loading plugins using the
> "egg:" protocol that we could use... it's just a matter of
> integrating it with identity :)
>
> Identity is going to be refactored out into separate middleware
> components for TG 2.0 (visit, authorization and authentication) but
> moving to setuptools for loading plugins could be done in 1.1 *if it
> adheres to the current API as much as possible*. If anyone wants to
> take a shot at it the trunk is open :)

I've spent enough time futzing with entry_points that I think I can
handle it. I'll come up with a list of all the places that they can be
used if you will give me the access to change it. (I know I have
commit access to something, but I think it might only be the website)

-Adam

Adam Jones

unread,
Jan 29, 2007, 4:10:13 PM1/29/07
to TurboGears Trunk
Per the discussion on "fork the 1.1 branch (and the wish list)?"
should I make a 1.1-plugin-refactor branch to handle this? It will
take me a while to go through all of the code and come up with a list
of possible targets, so I can wait a couple of days until that debate
has settled if need be.

-Adam

Alberto Valverde

unread,
Jan 30, 2007, 9:01:39 AM1/30/07
to turbogea...@googlegroups.com

Feel free to make a branch out of trunk to experiment. In fact, it's
a very good idea IMO for complex changes in order to keep the trunk
always in an usable state so other developers can work on other areas
of the code simultaneously. However, as Jorge said, it'll be your
responsability to keep it in sync with the trunk and merge it back
when done.

Alberto

Reply all
Reply to author
Forward
0 new messages