[Chandler-dev] Re: [Design] [Proposal] Removing plugins and what
else for Preview?
vajda at osafoundation.org
Fri Feb 9 13:31:14 PST 2007
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 ?
More information about the chandler-dev