[Chandler-dev] Yet another proposal for Chandler plugins
twl at osafoundation.org
Tue Feb 13 14:30:45 PST 2007
So I'd like to give my perspective on all this, and it will mean
stepping back from the details.
The original issue was removal of the demo parcels. I opposed this
because I think that we need the demo parcels to spark the
imagination of users and developers as to the possibilities of
Chandler, beyond the feature set that will ship in Preview. But
really the audience is for developers, because without them, there
will be no plugins for users to install. So if we are going to
spend additional energy on this, I'd suggest that we spend the energy
on things which will help developers build plugins given what we
already have. I am a fan of all the work that has gone into eggs,
and I advocated that we adopt them for Chandler. But our experience
both at sprints and with interns suggests to me that the biggest
obstacle for developers is documentation, not a better mechanism for
plugin discovery and installation.
So I would submit that if this is our goal, then we ought to spend
our energy on better documentation for developers.
On Feb 9, 2007, at 4:24 PM, Andi Vajda wrote:
> After a lengthy conversation with PJE, I think the following is a
> much better proposal for handling plugins than what I've been
> floating before and it should make everyone happy as well:
> 1. Instead of shipping plugins, we should use cheeseshop for
> This has the following advantages:
> - We don't ship plugins anymore (makes Heikki happy)
> - We get a Chandler category on the cheeseshop site, making
> it easier
> for people to find or publish their own Chandler plugins.
> In order to get such a category, we (me) need to upload a
> few plugins
> (around three) and send them mail requesting it.
> - Every plugin gets a home page at cheeseshop that is easy
> to find
> and that:
> - sets expectations as to the level of quality and support
> for it
> - documents how to intall it or how to get/view its sources
> - otherwise documents its limits, scope, usage,
> capabilities, etc...
> That home page can be part of the plugin's long
> description or can
> be a link to our wiki.
> In other words, there already is infrastructure for plugin
> discovery that
> we should leverage instead of rolling our own: cheeseshop.
> 2. We should not ship the "projects" directory but instead create a
> "plugins" directory into which Chandler plugins would be
> installed by
> the end-user downloading them. That directory would be used
> both by the
> end-user to drop-in downloaded plugin eggs and by the end-
> developer for
> installing their own plugin(s). Our python setup can make sure
> "plugins" directory is where things go to by default.
> This "plugins" directory doesn't conflict with our own "projects"
> directory in any way.
> The indispensable "projects" such as egg-translations should
> move to
> "external", "internal", or "parcels".
> 3. We (me) should add a "Plugins" menu / UI facility that scans
> what is in
> that "plugins" directory so that the end-user can:
> - query which plugins are installed / not installed
> - point the default web browser to the 'Chandler'
> cheeseshop page
> (once we have a 'Chandler' category there)
> - download and install a plugin from cheeseshop
> - install a plugin
> - uninstall a plugin with repository cleanup that, in order of
> preference does one of the following:
> a. deletes all items created by the plugin
> b. undoes all repository versions since the plugin was
> c. restores a repository backup
> d. replaces the repository with a new, fresh one
> It important that this be done by Preview so that we can shake out
> bugs in both the setup, PJE's setuptools and have a solid solution
> for 1.0.
> Comments ?
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "chandler-dev" mailing list
More information about the chandler-dev