Plugins - part 1: the application. My interest in plugins started two years ago listening to Ivan Krstić talk about the OLPC. Following his talk, I wrote the following on edu-sig: One open issue (as I understand it) is that of finding the "best practice" for plugins. The idea is that the core programs should be as small as possible but easy to extend via plugins. I thought that there already was a "well known and best way" to design plugins - and it was on my list of things to learn about (to eventually incorporate rur-ple within crunchy).
After discussing this off-list with Johannes Woolard, I concluded that we should try to redesign Crunchy to make use of plugins. While I was thinking about how we might proceed to do this, Johannes went ahead and implemented a simple plugin framework which we eventually adopted for Crunchy. The application I have chosen is a small modification of an expression calculator written and described by Fredrik Lundh, aka effbot, a truly outstanding pythonista. Import re. Theatre of noise: An Architecture For Plugin Code in Python. I recently needed a framework that would allow a user to create a Python module of functions that could be accessed by custom scripts launched from a different module entirely. I think I've written similar code three or four times now, so it's about time I came to grips with the "pattern" involved. Like most things in Python, it's dead simple once you get your head around it.
Our example plugin module we'll call plugin.py and make as simple as possible: def Iron(): print 'Iron' def Gold(): print metal def Again(): Transform() print 'Plastic' I note that the second function appears to be referencing a variable metal that does not exist, and the third calls a function Transform that also seems to be missing in action. That module is named master.py and looks like this: import os, sys class Alchemy(object): def __init__(self, filespec): # add module to system path filepath, filename = os.path.split(filespec) if filepath not in sys.path: sys.path.append(filepath) # ok, go for it!
Twisted Documentation: The Twisted Plugin System. The purpose of this guide is to describe the preferred way to write extensible Twisted applications (and consequently, also to describe how to extend applications written in such a way). This extensibility is achieved through the definition of one or more APIs and a mechanism for collecting code plugins which implement this API to provide some additional functionality. At the base of this system is the twisted.plugin module. Making an application extensible using the plugin system has several strong advantages over other techniques: It allows third-party developers to easily enhance your software in a way that is loosely coupled: only the plugin API is required to remain stable. Writing Extensible Programs Taking advantage of twisted.plugin is a two step process: Define an interface which plugins will be required to implement.
As an example of the first step, consider the following interface definition for a physical modelling system. Extending an Existing Program Alternate Plugin Packages. Termie / SprinklesPy. Documentation/PyUtilibOverview – PyUtilib. EnvisageThree/Index – ETS. This wiki and issue tracer contain documentation of the Enthought Tool Suite through January 2011, and are still useful for reference. We are gradually migrating these reference pages to the current ETS site . Please submit all new issues and comments to the ETS github site. Welcome to the Envisage Project! Given the title, the first questions you probably have are "What is an 'extensible application'? " You may have noticed that virtually every application these days has some concept of "plugins".
The goal of the Envisage project is to provide a general framework for building extensible, pluggable applications and in particular (but not limited to!) Like all of the code in the Enthought Tool Suite, Envisage is open-source with BSD-style licensing so you can include it for free in any of your commercial applications. Documentation ¶ Introduction To Envisage (read this first, no seriously, it will help...) The Good Ol' "Hello World" example Notes Roadmap. Colony Framework. Colony aims to eliminate the complexity typically associated with the creation of modular applications, through a simplified unified model for component development. Practical applications can range from modular enterprise software to application mashing.[2] Motivation[edit] Colony aims to be a platform and language independent specification, and serve a wide range of use cases.[3] This includes use cases typically associated with OSGi, such as modularized application with a narrow core and large extensibility possibilities.
This also includes use cases to which MEF caters, such as adding modularity to an existing application, without the developer having to create its own plugin infrastructure from scratch. The need for reducing the number of configuration steps for assembling a computing grid, as well as supporting adding nodes and distributing computation to them as quickly as possible, also drives the Colony Distributed initiative.
Key concepts[edit] Distribution[edit] Status[edit]