PluginArchitecture

From PyMOLWiki
Jump to: navigation, search

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.

Contents

Overview

PyMOL enjoys widespread use as 3D molecular visualization program with strengths in rendering and visualization. PyMOL at current does not have a robust extension mechanism for adding new plug-in based features to PyMOL. It only allows a script of one file and has very limited support for installation and removal. This project aims to correct that lacking functionality. We aim for simplicity and robustness especially in a cross-platform manner.

A Plug-In (or Plugin) is a modular piece of software that extends PyMOL's functionality.

Wanna' Help?

If you want to take part in helping out with this, please send Jason Vertrees an email letting him know as such.

PyMOL OS Fellowship Project 2011/2012

Thomas Holder will work on the new plugin system as part of his 2011-2012 Fellowship.

Code repository: https://github.com/speleo3/pymolplugins

Status of the current work in progress:

Major goals in roadmap:

Review of Current Plugin System

Essentially the current system inits all the scripts in the startup directory, which adds their entry to the Plugins menu. When called, it fires off a command passing to it PyMOL's Tk menu. The instance can get access to pymol's cmd layer with,
from pymol import cmd
. Also, as it's in Python, the user can extend Python (even in C) or call low-level functions utilizing the web or touching the file system.

Ideas/Features for the New Plugin System

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.

Meeting Notes

May 3, 2010

In attendance: Nathan Baker, Mike Beachy, Greg Landrum, David Gohara, Yong Huang, Jay Ponder, Jason Vertrees

Additional ideas people wanted to see implemented:

Liked Plugin Systems

Disliked Plugin Systems

Links on the topic

The Name

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox