[PEAK] Eclipse for Python/PEAK development

[Phillip J. Eby]

I finally got around to giving Eclipse 3.0 a whirl, and thought I'd share 
my initial impressions, as they relate to developing on/in PEAK.  (There 
may also be some strategic long-term implications of a link between Eclipse 
and PEAK.)

First, I have to say that I was absolutely stunned by the speed and look 
and feel.  I don't remember when I last looked at Eclipse, but it's a 
major, major upgrade.  It's very fast, slick, and professional, and mostly 
it's been very easy to find the configuration knobs for things.  To my 
recollection, I have *never* seen a Java application that was so fast, 
visually clean, and responsive.  On Windows at least, it runs like a native 
application.  (I haven't tried it on any other platform, although it is 
also available for Linux, OS/X, Solaris, HP/UX, and AIX.)

Actually, I guess I should back up a moment in case anybody doesn't know 
what Eclipse is.  It's an all-purpose open source IDE: a programmer's 
editor crossed with a GUI for CVS, that includes extensible frameworks for 
all sorts of programming activities such as building, running, and 
debugging programs.  Dozens of "plugins" (both open source and proprietary) 
are available to perform specialized functions from applying XSLT 
stylesheets to debugging PHP scripts.  There's even a 'vi' plugin for folks 
who can't live without modal editing...  (Yes, I'm talking about you, Lynn.  :)

I've been keeping an eye on Eclipse for a few years now as potentially 
strategically useful for PEAK.  IDE's can play an important role in any 
"enterprise" development effort -- at least from a marketing 
perspective!  (For example, Ty and I once heard an argument that one of our 
products was "useless" because it didn't have an IDE, and it would cost 
"millions" to develop one...)

Anyway, I've been putting off actually learning to use Eclipse, because 
using it sounded complicated.  Nearly every tutorial I've seen talks about 
"views" and "perspectives" and makes it all sound very intricate.  However, 
once I actually  just ran the thing and played with it for a few minutes, 
it's easy to see that a "view" is just a window, and a "perspective" is 
just a virtual desktop.  That is, to "change perspectives" is just to 
switch between desktops that have a different set of windows open.  The 
only difference is that lots of useful desktops have already been set up 
for you, and the environment has some intelligence about automatically 
switching desktops under certain circumstances.

The thing that took me longest to figure out was how to get its CVS 
integration to use my existing SSH configuration, as I currently use 
Cygwin's SSH, and I wanted to use my existing checkout of PEAK.  If I had 
been okay with using a fresh checkout it would have been much easier to set 
up; you can import your existing private keys, for example.

The CVS integration has some really slick features, such as side-by-side 
diffs, with lines drawn between the differences -- and you can *edit* the 
file in the side-by-side view, e.g. for resolving conflicts.  The current 
status of files is integrated into the regular IDE file browsing view, so 
you don't have to open anything else to see your current status.

For editing support, I installed two plugins: Colorer, and PyDev.  Colorer 
is an all-purpose syntax highlighter that supports numerous languages, 
including Python.  PyDev is a Python-specific syntax highlighter with 
editing functions, outlining, and a graphical debugger for 
Python.  (Outlining, by the way, is an Eclipse facility whereby a view 
shows an outline of the classes, functions, XML elements, etc. in a file 
that you're working on.)

I wasn't able to get the debugger to work with Python 2.2, apparently it 
requires 2.3.  It also seems to have a few problems with things like 
getting its global namespace confused when executing module-level code, and 
it won't let you set breakpoints in code that isn't part of your project 
(such as standard library modules).  It also seems a bit slow compared to 
using Python's built-in debugger.  (This is probably because it 
communicates via a TCP/IP connection, and it's always updating the variable 
display.  Switching off the variable display when you're not using it seems 
to speed it up a bit.)

The Colorer plug-in worked pretty decently with PEAK's non-Python 
files.  It seems to understand our .ini files quite well, even highlighting 
quoted strings, comments, and headings.  It generates an outline of the 
headings, so in a large .ini file like peak.ini you can jump to the section 
you're looking for by scanning the list of section names, and 
double-clicking the one you want.  The only thing it didn't handle 
correctly was that it interpreted '* = something' as a comment.  There are 
also a lot of words it thinks are keywords, but I imagine that I can 
probably change its .ini syntax file to fix that.  It would also be nice if 
it made outline entries for the settings themselves, but no-go.

Colorer's XML editor works nicely with PEAK's .pwt files, once you've 
configured Eclipse's "file associations" to use it.  However, it doesn't 
support any DTD or schema knowledge to make editing ZConfig schemas any 
easier.  I'll probably have to get a different plug-in for that.  There are 
several open source and proprietary "XML helper" plugins out there, but I 
haven't tried any yet.

Plugins in general appear to be a fairly mixed bag.  Some are very 
professional, such as the ones provided by Eclipse itself.  Often the open 
source ones lack polish, and it makes the UI messy at times.  For example, 
instead of adding Run and Debug functions to the existing Run and Debug 
context menus, the PyDev plugin registers a separate "Python" context menu 
to hold these functions for no apparent reason.  Eclipse plugins can add 
items to any existing menu they like, so there's no reason to create tons 
of separate menus, but a lot of plugins seem to.  It reminds me a bit of 
the Windows "Start" menu where everybody wants their product to have a menu 
entry, and nobody seems to support you installing their product into your 
personal categorization of the items.  I actually suspect that I could 
fiddle with this by just editing the plugins' manifest files to extend the 
menus I want them to extend, but I haven't gotten around to trying it.

Of course, if I really want to change the plugins, Eclipse has built-in 
plugins for developing plugins, at least if you don't mind working with 
Java.  I'm hoping, though, that the JPype project ( http://jpype.sf.net/ ) 
will hurry up and make it possible to write Eclipse plugins with 
Python.  However, if they take too long, I might be tempted to see if I can 
configure Eclipse to automatically build .java files from .jy files using 
'jythonc'.  I seem to recall seeing some options for incremental/background 
builds somewhere...

But I'm kind of heading off-topic now.  Eclipse is cool, but so 
what?  Well, since it's open source, we could actually (for example) create 
totally customized PEAK IDEs.  There are UML editors for Eclipse that we 
could potentially read XMI files from to generate code.  If somebody is 
creating an enterprise-class application that needs an IDE for 
customization purposes, they could then take the PEAK IDE and just add in 
some specialty tools for their specific application, while still using the 
base parts defined by PEAK.  Further, if the JPype folks do come through, 
and we can talk to pure Python from Eclipse code, I can foresee creating 
things like a graphical namespace navigator, or using the Eclipse RCP (Rich 
Client Platform) to create GUI applications outside the IDE.  (The Eclipse 
IDE is built atop a microkernrel runtime engine that supports automatic 
software updates and installation, among other useful-to-have features.)

So, this is all rather far-off still, but a lot closer than it was a couple 
of years ago when I was first looking at Eclipse.  The short-term effect is 
probably just going to be that I'll move from using jEdit to Eclipse for my 
development of PEAK, and sometime soon I may begin playing with plugin 
development, in the interests of making some more PEAK-specific tools, such 
as maybe a "smart" .ini file editor, or maybe IDE-level support for 
interfaces, decorators, and so forth.

Of course, I can already see that route becoming a tempting distraction 
from all the work I already have on my plate, such as finishing generic 
functions, defining the API for PyProtocols 1.0, and doing all the many 
things on the TODO list for 0.5a4.  On the bright side, Eclipse has a 
built-in task tracker that I can now use for tracking many such items.  :)

(Which reminds me -- we need to do something about TODO lists for PEAK in 
general, as the text-based mechanisms used to date are increasingly 
unwieldy, and release planning needs an overhaul too.  But these are 
subjects for another time.)