On Fri, 9 Feb 2007, Katie Capps Parlante wrote:

Phillip J. Eby wrote:
(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.)

Would it be reasonable to do this in Preview, or is this a post-Preview-when-plugins-are-more-developed task?

Phillip's proposal has the advantage that's it's the least amount of work for us. It has the disadvantage though that there isn't much of a chance of having plugins on cheeseshop work well with a moveable target such as Chandler post Preview before 1.0.

I think post Preview, for the 1.0 release, it's definitely the way to go

Maybe I'm wrong and we should experiment with cheeseshop as a deployment base for plugins for Preview as well. If we do this in Preview, we need to at least set expectations correctly and help users not hose themselves with plugins that are incompatible with the chandler they're being installed in.

Phillip also mentioned a 'source release'. I've always thought that the sources of chandler (the chandler tree) would be shipped with all our releases. Egg files are great but they go to extra lengths in being hidden in python's site-packages and they're actually masqueraded .zip files.

For the sake of faster start (hard to believe unzipping is faster than not but I could be wrong), having everything as .egg files is good but hiding the sources is not.

I guess, my main concern over all of this is that we shouldn't be making it harder for developers to play with chandler plugins. End-users can use a developer-friendly release just as well.

To sum up my confused thoughts:

 - +1 to .egg files everywhere

 - +1 for adding a menu item to chandler to access chandler plugins from
   cheeseshop (are there APIs for doing this besides screen-scraping ?)

 - -1 to not shipping sources or making it any harder for devs to play with
   things, in other words:
   - -1 to requiring a separate, dev release
   - -1 to requiring 'svn co'

   If we have eggs everywhere and they (are made to) contain sources, maybe
   a simple command to unpack the sources and remove the .egg zip file such as
   'setup.py develop' can satisfy what I'm trying to advocate ?

Andi..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev

Reply via email to