After reviewing this with Andi, this seems reasonable from a design
standpoint. The only issue being that when users uninstall plug-ins,
there will most likely be data loss. We will need to roll back the
repository to the state it was in 'before' the plug-in was installed,
thereby deleting any edits the user has made to their data since then.
As a result, we need to have verbiage to warn users that plug-ins are
not safe to try out if you're actually trying to use the app. (I know
it's technically not true, but it gets the point across.)
Warning: Do not install plug-ins if you have real data in Chandler.
Doing so will result in data loss.
We also need to warn users when they uninstall:
Uninstalling xxx will undo all edits and delete any new items you've
created since xxx, when you first installed the plug-in.
[Cancel] [Uninstall]
Mimi
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 "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
