Difference between revisions of "PluginArchitecture"

From PyMOLWiki
Jump to: navigation, search
(Links on the topic)
(Ideas/Features for the New Plugin System)
Line 4: Line 4:
  
 
= Ideas/Features for the New Plugin System =
 
= Ideas/Features for the New Plugin System =
 +
* Plugins must be ''safe''. That is, they must not destroy the users' data for file system.
 +
* Plugins must be ''secure'' in that they do not transmit data the user doesn't want transmitted.
 +
** We can take an approach like Warren did with sessions--warn the user on sessions s/he didn't create and ask for trusting or not.
  
 
== More than one file per plugin ==
 
== More than one file per plugin ==

Revision as of 11:30, 10 April 2010

This page concerns the development for new PyMOL Plugin Architecture. We are requesting ideas, code, etc on how to best implement a successful plug in system.

Review of Current Plugin System

Ideas/Features for the New Plugin System

  • Plugins must be safe. That is, they must not destroy the users' data for file system.
  • Plugins must be secure in that they do not transmit data the user doesn't want transmitted.
    • We can take an approach like Warren did with sessions--warn the user on sessions s/he didn't create and ask for trusting or not.

More than one file per plugin

I'd like plugins that behave like proper Python modules with the ability to span multiple files/directories. One simple way to do this would be to distribute plugins as zip files. E.g. if we have a directory Foo that contains

MyMod
    __init__.py
          """Some documentation here"""
    Foo.py
        def doit():
            print "It is done!"

We can zip it up like

zip MyMod.zip Foo/*

If you stick MyMod.zip in a plugins directory like /blahblah/Pymol/plugins/MyMod.zip you can then say this:

sys.path.append('/blahblah/Pymol/plugins/MyMod.zip')
from MyMod import Foo
Foo.doit()

Python does not impose the restriction that the module/directory name (MyMod) should be the same as the zip file name (MyMod.zip), but we might want to.

Then we need to formally spell out the API by which the Plugin is launched.

This makes it very easy to install/uninstall plugins, and PyMOL can just have a simple loop that iterates over the plugins directory, adds the appropriate things to sys.path, verifies that the resulting objects support the API, and adds them to the menu.

Config files

Some sort of persistent config files where users can store things like paths to relevant files, settings, etc. would be very useful. The APBS plugin, for instance, is a bit of a bother to use when you have APBS installed in a non-standard location. It would be very convenient if you could set the location once and have it persist.

Liked Plugin Systems

Disliked Plugin Systems

Links on the topic

The Name

  • Plugins, Plug-Ins?
  • Add-ons?
  • Extensions?