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:
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007608.html
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
starts.
(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.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
