[Chandler-dev] Re: [Design] [Proposal] Removing plugins and what else for Preview?

Phillip J. Eby pje at telecommunity.com
Fri Feb 9 13:09:48 PST 2007

At 12:39 PM 2/9/2007 -0800, Katie Capps Parlante wrote:
>We've been discussing how to handle plugins on the chandler-dev list, and 
>I think we've hit on some topics that really belong on design, so moving 
>the conversation.
>For background on the conversation that followed Heikki's initial message, 
>check out the dev-list thread:
>Ok, new proposal...
>+ Do not remove plugins from end-user release
>    - have them be "disabled" by default, not loaded
>    - leave the projects/ and samples/ directories in the distribution
>    - have a menu item that "turns on" or "enables" plugins

Er, I think there may be some confusion here about how plugins are intended 
to work in a distributed environment.

Plugins are designed to be shipped as .egg files, placed in an appropriate 
directory (e.g. parcels, site-packages, or some other designated directory).

They should never be shipped as projects/ subdirectories for a production 
Chandler instance, any more than we would ship the externals/ directory and 
contents thereof.

The way that you activate or "install" a distributed plugin is to place the 
.egg file in the designated directory, where it's picked up when Chandler 

(Note, by the way, that if we publish our plugins on the Python Cheeseshop, 
we could add a menu item that allows you to type the name of a plugin, and 
cause it to be downloaded and installed, using the included easy_install 
feature of setuptools.)

So, just to clarify, there should be no question about whether projects/ 
ship with Chandler.  They should NOT, as they're part of the Chandler 
*build*, not the distribution.

The only questions about the plugins should be, do we want to ship the .egg 
files and do we want them activated.  We should only be shipping the 
projects/ tree with Chandler *source* distributions.

(By the way, one reason for doing this is that Chandler will start faster 
with .egg file plugins than with projects/ directory plugins.  Indeed, it 
might be worth considering bundling up the entire parcels/ tree as an .egg 
too, for this very reason.)

>- some potential developers will grab the end-user release -- lightweight 
>plugin development should be doable with the end-user release (long term 
>goal); basically we don't want to *hide* the idea of plugins from people 
>(developers or users), we want to do the opposite

Note that this use case can be met by publishing plugin releases to the 
CheeseShop, including source distributions.  As long as you have a working 
Chandler installation and you can run its Python, you can do plugin 
development using the standard tools of "setup.py develop" (to do live 
development) and "setup.py install" (to build an .egg and install it).

You can then publish your developed plugin using "setup.py sdist bdist_egg 
register upload", which will register the plugin with the Cheeseshop, build 
source and binary distribution files, and upload them to the CheeseShop.

And, if we have a test/tools/demo/whatever menu item that allows you to 
type in a plugin name and pull it down from the CheeseShop, then it's all 
good to go -- we have at that point all the community infrastructure needed 
to develop, distribute, and deploy user-contributed plugins.

More information about the chandler-dev mailing list