gmane.comp.python.enthought.devel

Proposal to change the declaration of Envisage plugins in eggs...

G'day,

As some of you may know Envisage ships with a plugin manager that harvests plugins from eggs (the
'EggPluginManager'). The egg plugin manager is very simple(istic!) as it assumes that every plugin
in every egg in the working set (i.e. on sys.path) should be included in your application.

Now, (not coincidentally!), that works just fine for the way that we here at Xype distribute our
applications! We put all of the eggs that are used in an application into what we call an 'egg
basket' and dynamically add the eggs to the working set when the application starts up.

However, this approach does not work nicely if you don't use the egg basket approach and you want to
specify a subset of the plugins on your path to make up your application (which BTW, is how most of
the egg-based test cases and examples work).

The 'EggPluginManager' already supports the notion of an 'include' list, which is simply a list of
the Ids of the plugins that you want to actually use (we should also have an 'exclude' list of
course, but I'll defer that to another test case ;^). Howeever, the problem with the current scheme
is that we don't know the Id of a plugin until we have imported and instantiated it which is quite
smelly if you ask me!

To fix this, I propose changing the way we declare plugin entry points in 'setup.py' modules.

Currently, it looks something like this (taken from the MOTD example):-

entry_points = """

[enthought.envisage.plugins]
motd = acme.motd.motd_plugin:MOTDPlugin

"""

(Continue reading)

headers

Robert Kern | 2 Dec 21:53

Re: Proposal to change the declaration of Envisage plugins in eggs...

On Tue, Dec 2, 2008 at 06:48, Martin Chilvers
<martin.chilvers@...> wrote:
> G'day,
>
> As some of you may know Envisage ships with a plugin manager that harvests plugins from eggs (the
> 'EggPluginManager'). The egg plugin manager is very simple(istic!) as it assumes that every plugin
> in every egg in the working set (i.e. on sys.path) should be included in your application.
>
> Now, (not coincidentally!), that works just fine for the way that we here at Xype distribute our
> applications! We put all of the eggs that are used in an application into what we call an 'egg
> basket' and dynamically add the eggs to the working set when the application starts up.
>
> However, this approach does not work nicely if you don't use the egg basket approach and you want to
> specify a subset of the plugins on your path to make up your application (which BTW, is how most of
> the egg-based test cases and examples work).
>
> The 'EggPluginManager' already supports the notion of an 'include' list, which is simply a list of
> the Ids of the plugins that you want to actually use (we should also have an 'exclude' list of
> course, but I'll defer that to another test case ;^). Howeever, the problem with the current scheme
> is that we don't know the Id of a plugin until we have imported and instantiated it which is quite
> smelly if you ask me!
>
> To fix this, I propose changing the way we declare plugin entry points in 'setup.py' modules.
>
> Currently, it looks something like this (taken from the MOTD example):-
>
>     entry_points = """
>
>     [enthought.envisage.plugins]
>     motd = acme.motd.motd_plugin:MOTDPlugin

(Continue reading)

headers

Martin Chilvers | 4 Dec 14:23

Re: Proposal to change the declaration of Envisage plugins in eggs...

G'day,

The proposal has now been implemented and checked into the trunk. This requires some action on the 
part of plugin writers (I have fixed up the EnvisageCore and EnvisagePlugins projects), but it won't 
break anything unless you use the egg plugin manager *and* you were filtering the plugins using the 
'include' trait...

1) Make sure that you give *all* plugins a sensible Id.

e.g.

class FooPlugin(Plugin):
     id = 'acme.foo'

2) Make sure that in the 'setup.py' files the LHS of the entry points is the same as the plugin Id.

e.g.

[enthought.envisage.plugins]
acme.foo = acme.foo.foo_plugin:FooPlugin

For now, if the LHS is *not* the same as the plugin Id, you will get a logger warning if and when 
the plugin is created. Later we will probably be stricter and simply barf!

3) That's it!

Martin

Robert Kern wrote:
> On Tue, Dec 2, 2008 at 06:48, Martin Chilvers

(Continue reading)

headers

Prabhu Ramachandran | 4 Dec 16:59

Re: Proposal to change the declaration of Envisage plugins in eggs...

Martin Chilvers wrote:
> The proposal has now been implemented and checked into the trunk. This requires some action on the 
> part of plugin writers (I have fixed up the EnvisageCore and EnvisagePlugins projects), but it won't 
> break anything unless you use the egg plugin manager *and* you were filtering the plugins using the 
> 'include' trait...
> 
> 1) Make sure that you give *all* plugins a sensible Id.
> 
> e.g.
> 
> class FooPlugin(Plugin):
>      id = 'acme.foo'
> 
> 2) Make sure that in the 'setup.py' files the LHS of the entry points is the same as the plugin Id.

The setup.py modification is only for apps that use a plugin, right?

cheers,
prabhu

headers

Martin Chilvers | 4 Dec 17:04

Re: Proposal to change the declaration of Envisage plugins in eggs...

Prabhu Ramachandran wrote:
> Martin Chilvers wrote:
>> The proposal has now been implemented and checked into the trunk. This requires some action on the 
>> part of plugin writers (I have fixed up the EnvisageCore and EnvisagePlugins projects), but it won't 
>> break anything unless you use the egg plugin manager *and* you were filtering the plugins using the 
>> 'include' trait...
>>
>> 1) Make sure that you give *all* plugins a sensible Id.
>>
>> e.g.
>>
>> class FooPlugin(Plugin):
>>      id = 'acme.foo'
>>
>> 2) Make sure that in the 'setup.py' files the LHS of the entry points is the same as the plugin Id.
> 
> The setup.py modification is only for apps that use a plugin, right?

Exactly. You only need to change the [enthought.envisage.plugins] entry points.

Martin

headers

Prabhu Ramachandran | 4 Dec 17:17

Re: Proposal to change the declaration of Envisage plugins in eggs...

Martin Chilvers wrote:
> Prabhu Ramachandran wrote:
>> Martin Chilvers wrote:
>>> The proposal has now been implemented and checked into the trunk. This requires some action on the 
>>> part of plugin writers (I have fixed up the EnvisageCore and EnvisagePlugins projects), but it won't 
>>> break anything unless you use the egg plugin manager *and* you were filtering the plugins using the 
>>> 'include' trait...
>>>
>>> 1) Make sure that you give *all* plugins a sensible Id.
>>>
>>> e.g.
>>>
>>> class FooPlugin(Plugin):
>>>      id = 'acme.foo'
>>>
>>> 2) Make sure that in the 'setup.py' files the LHS of the entry points is the same as the plugin Id.
>> The setup.py modification is only for apps that use a plugin, right?
> 
> Exactly. You only need to change the [enthought.envisage.plugins] entry points.

OK, cool.  I've done (1) now for the mayavi and tvtk plugins and given 
them explicit IDs.  I guess thats all I need to do.

cheers,
prabhu

headers

Martin Chilvers | 4 Dec 19:24

Re: Proposal to change the declaration of Envisage plugins in eggs...

G'day,

Prabhu Ramachandran wrote:
> Martin Chilvers wrote:
>> Prabhu Ramachandran wrote:
>>> Martin Chilvers wrote:
>>>> The proposal has now been implemented and checked into the trunk. This requires some action on the 
>>>> part of plugin writers (I have fixed up the EnvisageCore and EnvisagePlugins projects), but it won't 
>>>> break anything unless you use the egg plugin manager *and* you were filtering the plugins using the 
>>>> 'include' trait...
>>>>
>>>> 1) Make sure that you give *all* plugins a sensible Id.
>>>>
>>>> e.g.
>>>>
>>>> class FooPlugin(Plugin):
>>>>      id = 'acme.foo'
>>>>
>>>> 2) Make sure that in the 'setup.py' files the LHS of the entry points is the same as the plugin Id.
>>> The setup.py modification is only for apps that use a plugin, right?
>> Exactly. You only need to change the [enthought.envisage.plugins] entry points.
> 
> OK, cool.  I've done (1) now for the mayavi and tvtk plugins and given 
> them explicit IDs.  I guess thats all I need to do.

Well, you need to do 2) as well to allow people to use the egg manager to filter out Mayavi eggs by 
Id if necessary.

Martin

(Continue reading)

headers

Prabhu Ramachandran | 4 Dec 19:34

Re: Proposal to change the declaration of Envisage plugins in eggs...

Martin Chilvers wrote:
>> OK, cool.  I've done (1) now for the mayavi and tvtk plugins and given 
>> them explicit IDs.  I guess thats all I need to do.
> 
> Well, you need to do 2) as well to allow people to use the egg manager to filter out Mayavi eggs by 
> Id if necessary.

Thanks for mentioning this.  Done.

cheers,
prabhu