plugin development best practices

Discussion in 'Python' started by Flavio, Feb 22, 2007.

  1. Flavio

    Flavio Guest

    Hi,

    Nowadays the addition of functionality to programs by means of
    plugins is very frequent.

    I want to know the opinions of experienced Python developers about the
    best practices when it comes to developing a plugin system for a
    Python package.

    Should plugins be modules in a separate package?
    Should there be a registry of available plugins? how would such a
    registry be implemented? etc.

    thanks,

    Flávio
    Flavio, Feb 22, 2007
    #1
    1. Advertising

  2. Flavio wrote:

    > Hi,
    >
    > Nowadays the addition of functionality to programs by means of
    > plugins is very frequent.
    >
    > I want to know the opinions of experienced Python developers about the
    > best practices when it comes to developing a plugin system for a
    > Python package.
    >
    > Should plugins be modules in a separate package?
    > Should there be a registry of available plugins? how would such a
    > registry be implemented? etc.


    There have been a gazillion discussions about this on this newsgroup/mailing
    list. Searching the archives will get you to them.

    The dynamic nature of python makes a whole range of options available.
    Depending on what you want to do (how are the plugins made available and so
    on), one or the other might be preferable.

    One relatively current development is the usage of setuptools "entry-points"
    feature, which is precisely made for discovering installed plugins:

    http://peak.telecommunity.com/DevCenter/setuptools#dynamic-discovery-of-services-and-plugins


    Diez
    Diez B. Roggisch, Feb 22, 2007
    #2
    1. Advertising

  3. Flavio

    Flavio Guest

    On Feb 22, 11:00 am, "Diez B. Roggisch" <> wrote:
    > Flavio wrote:
    > > Hi,

    >
    > > Nowadays the addition of functionality to programs by means of
    > > plugins is very frequent.

    >
    > > I want to know the opinions of experienced Python developers about the
    > > best practices when it comes to developing a plugin system for a
    > > Python package.

    >
    > > Should plugins be modules in a separate package?
    > > Should there be a registry of available plugins? how would such a
    > > registry be implemented? etc.

    >
    > There have been a gazillion discussions about this on this newsgroup/mailing
    > list. Searching the archives will get you to them.
    >
    > The dynamic nature of python makes a whole range of options available.
    > Depending on what you want to do (how are the plugins made available and so
    > on), one or the other might be preferable.
    >
    > One relatively current development is the usage of setuptools "entry-points"
    > feature, which is precisely made for discovering installed plugins:
    >
    > http://peak.telecommunity.com/DevCenter/setuptools#dynamic-discovery-...
    >
    > Diez


    Thanks Diez,

    I will search the archives. I am aware of the setuptools feature It is
    quite nice. But the documentation is not very clear on how to define
    "entry point groups" on the importing end, i.e. how to prepare a an
    application to accept plugins it doesn't even now exist.

    Flavio
    Flavio, Feb 22, 2007
    #3
  4. >
    > I will search the archives. I am aware of the setuptools feature It is
    > quite nice. But the documentation is not very clear on how to define
    > "entry point groups" on the importing end, i.e. how to prepare a an
    > application to accept plugins it doesn't even now exist.


    The entry-points are just a method of discovery. Writing a plugin by
    itself - if that is what you are talking about here - is usually done by
    exposing a certain interface, and invoking some registration
    functionality - after the plugin is discovered, that is.


    Diez
    Diez B. Roggisch, Feb 22, 2007
    #4
  5. Flavio

    Flavio Guest

    On Feb 22, 11:01 am, Jean-Paul Calderone <> wrote:
    > On 22 Feb 2007 04:53:02 -0800, Flavio <> wrote:
    >
    > >Hi,

    >
    > >Nowadays the addition of functionality to programs by means of
    > >plugins is very frequent.

    >
    > >I want to know the opinions of experienced Python developers about the
    > >best practices when it comes to developing a plugin system for a
    > >Python package.

    >
    > >Should plugins be modules in a separate package?
    > >Should there be a registry of available plugins? how would such a
    > >registry be implemented? etc.

    >
    > >thanks,

    >
    > Best practice may be to not develop a new plugin system. There are quite a
    > few available already. Most likely, at least one of them is suitable for your
    > application.
    >
    > Here are a couple starting points:
    >
    > http://twistedmatrix.com/projects/core/documentation/howto/plugin.html
    >
    > http://peak.telecommunity.com/DevCenter/setuptools#dynamic-discovery-...
    >
    > Jean-Paul


    The plugin system provided by twisted looks interesting (though not as
    simple as it could be, IMHO). Its main problem is that it introduces
    two dependencies : Twisted plugin and ZopeInterface. I think a
    functional plugin system could(and should) be done using only the
    standard library.

    Flávio
    Flavio, Feb 22, 2007
    #5
  6. Flavio

    Flavio Guest

    On Feb 22, 10:53 am, "Flavio" <> wrote:
    > Hi,
    >
    > Nowadays the addition of functionality to programs by means of
    > plugins is very frequent.
    >
    > I want to know the opinions of experienced Python developers about the
    > best practices when it comes to developing apluginsystemfor a
    > Python package.
    >
    > Should plugins be modules in a separate package?
    > Should there be a registry of available plugins? how would such a
    > registry be implemented? etc.
    >
    > thanks,
    >
    > Flávio


    let me extend my original question with an example:

    Simple plugin system proposal:

    have a package (directory with __init__.py) called plugins where the
    actual plugins are modules in this directory.

    When the main script imports the plugins package, all plugin modules
    would be available as plugins.pluginA, plugins.pluginB , etc.

    A registry of available plugins would be available as a simple
    dir(plugins).

    code in the main script than wished to use a given plugin, would only
    have to look in the registry before calling any code from a given
    plugin.

    What is wrong/missing with this simple framework?

    I'd appreciate any comments.

    Flávio
    Flavio, Feb 22, 2007
    #6
  7. > Simple plugin system proposal:
    >
    > have a package (directory with __init__.py) called plugins where the
    > actual plugins are modules in this directory.
    >
    > When the main script imports the plugins package, all plugin modules
    > would be available as plugins.pluginA, plugins.pluginB , etc.
    >
    > A registry of available plugins would be available as a simple
    > dir(plugins).
    >
    > code in the main script than wished to use a given plugin, would only
    > have to look in the registry before calling any code from a given
    > plugin.
    >
    > What is wrong/missing with this simple framework?


    Nothing wrong. It's just one way of doing it. But it requires you to have
    all plugins being part of one module, in one location. Depending on what
    you want to do, this won't suffice. For example if your app is installed in
    a system path you aren't supposed to write to - how do you install your
    individual plugin? easy_install allows you to install to a folder that is
    contained in the PYTHONPATH, and then you can discover entrypoints.

    But please, do as we suggested: read the past discussions.

    Depending on what _you_ actually want to accomplish, you're proposal is
    enough. But don't expect it to become the "one plugin system to rule them
    all"-solution.

    diez
    Diez B. Roggisch, Feb 22, 2007
    #7
  8. Flavio

    Flavio Guest

    On Feb 22, 12:36 pm, "Diez B. Roggisch" <> wrote:
    > > Simple plugin system proposal:

    >
    > > have a package (directory with __init__.py) called plugins where the
    > > actual plugins are modules in this directory.

    >
    > > When the main script imports the plugins package, all plugin modules
    > > would be available as plugins.pluginA, plugins.pluginB , etc.

    >
    > > A registry of available plugins would be available as a simple
    > > dir(plugins).

    >
    > > code in the main script than wished to use a given plugin, would only
    > > have to look in the registry before calling any code from a given
    > > plugin.

    >
    > > What is wrong/missing with this simple framework?

    >
    > Nothing wrong. It's just one way of doing it. But it requires you to have
    > all plugins being part of one module, in one location. Depending on what
    > you want to do, this won't suffice. For example if your app is installed in
    > a system path you aren't supposed to write to - how do you install your
    > individual plugin? easy_install allows you to install to a folder that is
    > contained in the PYTHONPATH, and then you can discover entrypoints.
    >
    > But please, do as we suggested: read the past discussions.
    >
    > Depending on what _you_ actually want to accomplish, you're proposal is
    > enough. But don't expect it to become the "one plugin system to rule them
    > all"-solution.
    >
    > diez


    Oh, I have read all the links that have been suggested, but I am
    looking for the simplest possible solution.

    I have no intention to create the "next Plugin system" I am just
    trying to solve my own problem and in the process leave a record of a
    fruitfull discussion about plugin systems.

    BTW I have yet to check TRAC's plugin system.
    Flavio, Feb 22, 2007
    #8
  9. Flavio

    Flavio Guest

    On Feb 22, 12:51 pm, "Flavio" <> wrote:
    > On Feb 22, 12:36 pm, "Diez B. Roggisch" <> wrote:
    >
    >
    >
    > > > Simple plugin system proposal:

    >
    > > > have a package (directory with __init__.py) called plugins where the
    > > > actual plugins are modules in this directory.

    >
    > > > When the main script imports the plugins package, all plugin modules
    > > > would be available as plugins.pluginA, plugins.pluginB , etc.

    >
    > > > A registry of available plugins would be available as a simple
    > > > dir(plugins).

    >
    > > > code in the main script than wished to use a given plugin, would only
    > > > have to look in the registry before calling any code from a given
    > > > plugin.

    >
    > > > What is wrong/missing with this simple framework?

    >
    > > Nothing wrong. It's just one way of doing it. But it requires you to have
    > > all plugins being part of one module, in one location. Depending on what
    > > you want to do, this won't suffice. For example if your app is installed in
    > > a system path you aren't supposed to write to - how do you install your
    > > individual plugin? easy_install allows you to install to a folder that is
    > > contained in the PYTHONPATH, and then you can discover entrypoints.

    >
    > > But please, do as we suggested: read the past discussions.

    >
    > > Depending on what _you_ actually want to accomplish, you're proposal is
    > > enough. But don't expect it to become the "one plugin system to rule them
    > > all"-solution.

    >
    > > diez

    >
    > Oh, I have read all the links that have been suggested, but I am
    > looking for the simplest possible solution.
    >
    > I have no intention to create the "next Plugin system" I am just
    > trying to solve my own problem and in the process leave a record of a
    > fruitfull discussion about plugin systems.
    >
    > BTW I have yet to check TRAC's plugin system.


    I have look at Trac's component based pluging system and I liked it
    very much. If external dependencies is not an issue I believe this is
    the best solution.
    http://trac.edgewall.org/wiki/TracPlugins
    Flavio, Feb 22, 2007
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kevin Spencer
    Replies:
    2
    Views:
    439
    John Saunders
    Aug 6, 2003
  2. Amelyan
    Replies:
    2
    Views:
    482
    Steve C. Orr [MVP, MCSD]
    Apr 30, 2005
  3. Kevin Frey

    Best Practices for Web App Development ?

    Kevin Frey, Feb 3, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    490
    Raymond
    Feb 3, 2006
  4. Jean-Paul Calderone

    Re: plugin development best practices

    Jean-Paul Calderone, Feb 22, 2007, in forum: Python
    Replies:
    3
    Views:
    285
    Flavio
    Feb 22, 2007
  5. Intransition

    Plugin best practices

    Intransition, Jun 15, 2011, in forum: Ruby
    Replies:
    5
    Views:
    455
    Intransition
    Jun 16, 2011
Loading...

Share This Page