PluginArchitecture - Revision history

Cchem: 1 revision

2018-12-10T03:24:49Z

1 revision

Speleo3: document current architecture

2018-11-13T17:43:18Z

document current architecture

Show changes

Bell: 1 revision

2016-02-08T05:26:40Z

1 revision

Speleo3: 2011-2012 Fellowship project

2016-01-29T19:42:53Z

2011-2012 Fellowship project

Pyadmin: 20 revisions

2014-03-28T02:00:32Z

20 revisions

Speleo3: link to github.com/speleo3/pymolplugins

2012-01-11T09:23:06Z

link to github.com/speleo3/pymolplugins

Speleo3: PyMOL OS Fellowship Project 2011/2012

2011-11-27T12:04:19Z

PyMOL OS Fellowship Project 2011/2012

Speleo3: PluginDirectory

2011-06-30T15:40:09Z

PluginDirectory

BenEisenbraun: /* Ideas/Features for the New Plugin System */

2010-08-04T17:32:10Z

Ideas/Features for the New Plugin System

New page

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.

= 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.

= 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, <source lang="python">from pymol import cmd</source>. 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.

* For a tutorial on the current system. see [[Plugins_Tutorial]].

= 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.
* Plugins should be able to query PyMOL for features
* PyMOL should take care of unpacking, installing, uninstalling, updating (?) the plugins
* '''MUST''' be backwards compatible with the current system
* '''MUST''' run cross platform
* Save user-specific information
* Support proxy information/setup for downloading scripts
* Support a personal plugin directory, so users can administer their own plugins in situations where the PyMOL installation is read-only and shared among many users.

== 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

<source lang="Python">
MyMod
__init__.py
"""Some documentation here"""
Foo.py
def doit():
print "It is done!"
</source>

We can zip it up like

<source lang="bash">
zip MyMod.zip Foo/*
</source>

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

<source lang="Python">
sys.path.append('/blahblah/Pymol/plugins/MyMod.zip')
from MyMod import Foo
Foo.doit()
</source>

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:
* As scripts will be accessing internal data for computation, improved access to PyMOL internal data structures, like DX maps, is required.
** I/O for maps is the rate limiting step;
** data structures can be large, so skipping the disk would also be nice
* Skeleton code for plugins would help people write new ones; good tutorial as well; we need to make things easier for the novice
** Make a new site for plugins: plugins dot pymol dot org?

= Liked Plugin Systems =
* [https://addons.mozilla.org/en-US/developers FireFox Devel/Docs]
* Google Chrome -- URL?

= Disliked Plugin Systems =

= Links on the topic =
* [http://stackoverflow.com/questions/323202/designing-extensible-software-plugin-architecture StackOverflow Discussion]
* [http://en.wikipedia.org/wiki/Open/closed_principle Dr. Meyers' Open/Closed Principle]
* [http://www.codeguru.com/cpp/misc/misc/plug-insadd-ins/article.php/c3879 Nice overview in C]

= The Name =
* Plugins, Plug-Ins?
* Add-ons?
* Extensions?

[[Category:Development]]
[[Category:Developers]]

Mglerner: /* More than one file per plugin */

2010-04-09T18:16:28Z

More than one file per plugin

@@ Line 11: / Line 11: @@
 = PyMOL OS Fellowship Project 2011/2012 =
-[[User:Speleo3|Thomas Holder]] will work on the new plugin system as part of his [http://pymol.org/fellowship 2011-2012 Fellowship].
+[[User:Speleo3|Thomas Holder]] was working on the new plugin system as part of his [http://pymol.org/fellowship 2011-2012 Fellowship]. The improvements were incorporated into PyMOL 1.5.0.5.
 * multiple files per plugin/module (see below: [[#More than one file per plugin]])
 * user plugin directory
 * rarely used plugins can be disabled for better performance and enabled on demand
 * metadata support (version, author, description, citation, tags, ...)
 * install from online repositories
@@ Line 43: / Line 37: @@
 * Save user-specific information
 * Support proxy information/setup for downloading scripts
 == More than one file per plugin ==

← Older revision		Revision as of 09:23, 11 January 2012
Line 12:		Line 12:

	[[User:Speleo3\|Thomas Holder]] will work on the new plugin system as part of his [http://pymol.org/fellowship 2011-2012 Fellowship].		[[User:Speleo3\|Thomas Holder]] will work on the new plugin system as part of his [http://pymol.org/fellowship 2011-2012 Fellowship].
		+
		+	Code repository: https://github.com/speleo3/pymolplugins

	Status of the current work in progress:		Status of the current work in progress:

← Older revision	Revision as of 03:24, 10 December 2018
(No difference)

← Older revision	Revision as of 05:26, 8 February 2016
(No difference)

← Older revision	Revision as of 02:00, 28 March 2014
(No difference)

@@ Line 8: / Line 8: @@
 == Wanna' Help? ==
 If you want to take part in helping out with this, please send Jason Vertrees an email letting him know as such.
 = Review of Current Plugin System =

@@ Line 20: / Line 20: @@
 We can zip it up like
-<source lang="bash"
+<source lang="bash">
 zip MyMod.zip Foo/*
 </source>