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.
Ted
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
publishing
plugins:
http://cheeseshop.python.org/pypi
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
the
"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
installed
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 ?
Andi..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
