What's PIDA?

From the PIDA home page:

PIDA is an IDE (integrated development environment). PIDA is different from other IDEs in that it will use the tools you already have available rather than attempting to reinvent each one. PIDA is written in Python with the PyGTK toolkit, and although is designed to be used to program in any language, PIDA has fancy Python IDE features.

Out of the box, some of those fancy IDE features are:

• Embedded vim or emacs as the editor
• Project organization, with per-project configurable run commands
• Real-time error checking
  
• SVN integration
• File browser
• Open buffer list
• Embedded terminals

PIDA has a plugin system that can be used to easily install more features like:

• Python source tree
• TODO parser
• Pastebin integration
• Trac bug list integration
• Graphical debugging

You can, of course, get most of this functionality for Plone development from IDEs like Wing or Eclipse (with PyDev Extensions) - but PIDA is 100% Free, and we like that :-)

Before we go any further, here's a screenshot of PIDA in action, debugging Plone's MembershipTool.py on a running Zope:

Ok, let's get started... 

Installing PIDA

You can download PIDA from the project download page. At the time of this writing, PIDA is at version 0.5.1.

Installation instructions are in the docs subdirectory of the tarball, but the basic steps for *nix systems are:

1. tar -xvf PIDA-0.5.1.tar.gz
2. cd PIDA-0.5.1
3. python setup.py build
4. python setup.py install

PIDA depends on PyGTK and a number of other dependencies. If the build fails, just read the traceback carefully and fix whatever it's complaining about. If you get stuck, ask for help on the PIDA users group.

Windows users: you can find some supplemental instructions for building PIDA on Windows here. Best of luck to you :)

Be sure to install PIDA and its dependencies using the same Python interpreter that your Zope uses! This will make it possible to use the integrated debugger with your Plone products.

Once you've got PIDA installed, run 'pida' from a terminal to start.

Configuring PIDA

The first time you run PIDA, you'll be prompted to select the editor that you want to use. The list may include vim, emacs, and possibly others, depending on what's installed on your system. I'm running Ubuntu 7.04 with vim and emacs installed, and those were the choices available to me.

Caution: I'm firmly on the vim side of the Editor Holy War, but I selected emacs just to see what the integration was like. This didn't work for me - when I launched PIDA, emacs would launch in its own window, but the PIDA UI would never load. This prevented me from going to PIDA's preferences to change my editor setting. If this happens to you, do the following:

• Exit emacs
• Kill any running PIDA processes
• Delete the file 'first_run_wizard' from ~/.pida2
• Relaunch PIDA and select vim as the editor. It's the right thing to do :-)

Installing Plugins

Once you've got PIDA up and running, you'll want to install a few plugins. Select Tools > Plugins Manager from the menu, then click Available Plugins in  the Plugins Manager panel. If the plugins list is empty, click Refresh at the bottom of the panel.

You'll want the following plugins at a minimum:

• Python - this is the Python source browser, which gives you an expandable tree of modules, classes, methods, etc
• Python Debugger - this is the debugger that we'll use to debug our code later in the tutorial. It's a remote Python debugger, modeled after (or perhaps taken from?) Winpdb.
  

Feel free to try out some more - I find the TODO parser plugin to be very useful.

To install any plugin, select it from the list then click Install/Upgrade.

Once you've got your plugins installed, it's time to create a project...

A 'project' in PIDA is a simple bookmark to a filesystem directory, and whatever execution commands you want to associate with it.

To create a new project:

• Select Project > Add Project from the menu. A file dialog will appear.
• Navigate to the directory that you want to use for the project root, then click Open (or OK, or whatever confirmation button your file dialog presents to you).
• If the directory you select has never been used for a PIDA project, you'll be prompted to create a new project file - click Yes.

Since PIDA's concept of a project is simple, you've got some flexibility in what you decide to use as a project root. If you're working on a single Plone product, you can use that product's directory. If you're working on multiple products in a single Zope instance, then you could use the instance Products directory as the project root. If you're using a buildout instead of an traditional instance, and you'd like to use PIDA to explore your entire buildout, then you can use the top-level directory of your buildout environment as the project root. It's up to you - do what works best for you.

Execution Controllers

Execution controllers are used to run your projects - or in our case, to run the Zope instance that we're using to test our product. We'll use zopectl (or 'instance' for buildouts) for our execution controllers. Let's start with a default controller to run Zope as a foreground process:

• Select your project in the project list
• From the menu, select Project > Project Properties. The properties panel will appear on the right side of the window.
• Enter 'Zope FG' or something similar in the Controller Name field
• Click 'Add'. Your new controller will appear in the controller list.
  
• Select your new controller in the controller list.
• In the field list below the controller list, click the 'value' field in the row labeled 'Execution Command'
• If you're using a traditional Zope instance, enter the full path to your instance's zopectl script, followed by 'fg':
  

  /path/to/zope/instance/bin/zopectl fg

• If you're using a buildout, enter the full path to the buildout instance script, followed by 'fg'
  

  /path/to/buildout/bin/instance fg

Once you've got your default execution controller set, test it by selecting Project > Execute Default from the menu. An embedded terminal window will appear in the bottom of the PIDA window, and you'll see the typical Zope startup messages, hopefully followed by the familiar "Zope Ready to handle requests". Use the ZMI in your web browser to shut down your instance when you need to. The terminal will display 'Child exited, press any key to close' once Zope has stopped.

Some other useful execution controllers and their commands, for example:

• Zope Debug - /path/to/zope/instance/bin/zopectl debug
• Test MyProduct - /path/to/zope/instance/bin/zopectl test -m Products.MyProduct

You could also set up controllers for zopectl start/stop/restart daemon commands, running your buildout script, or generating code with ArchGenXML. PIDA's execution controllers are just commands - each project has a specific set of controllers, but you can use them for non-project specific things. You could use them to tail your event log, check your mail, launch your web browser, or just about anything else you need.

Get to work!

At this point, you're ready to start using PIDA to develop your next great product - so you do just that. You're using PIDA's IDE features and your hard-earned vim muscle memory to write tests and content types with the greatest of ease. Everything's going great until... hmm. Something's not working.

Time to break out the debugger...

It's bound to happen sooner or later... in spite of your best efforts and meticulous tests, something goes wrong and you need to do some serious forensic debugging on your running Zope. Here's how you can use PIDA's remote Python debugger plugin to get it done:

1. Install the debugger plugin if you haven't done so already (see Getting Started). If you were not able to install PIDA into the same Python interpreter that runs your Zope, you should still be able to use the debugger. Just copy rpdb2.py from site-packages/pida/utils to somewhere in your your Zope's PYTHONPATH, and modify the breakpoint command to reflect the new location of rpdb2.py. (I haven't actually tried this, but I'm pretty sure it will work.)
2. Open your project, then open up the code you need to debug in the editor. Let's assume we're debugging Products/MyProduct/MyClass.py.
   
3. Insert the following line to set a breakpoint at the desired location:
   

   from pida.utils import rpdb2; rpdb2.start_embedded_debugger_interactive_password()

4. Save the file.
5. Activate the debugger by selecting Language > Python Debugger from the menu.
6. In the command line at the bottom-left of the debugger panel, enter password foo (change 'foo' to whatever password you want to use to connect to the debugger).
7. Start Zope using your project's execution controller, or restart Zope if it was already running. Keep this terminal window active for now.
   
8. Browse your site or do whatever it is you need to do to cause the breakpoint to execute.
9. When the breakpoint has executed, you'll see a password prompt in the controller terminal window. Enter the password you specified in step 6.
10. Switch to the debugger plugin.
11. In the debugger command line, enter attach - this will show you a list of running scripts (meaning Python files in your product) to which you can attach the debugger.
12. In the debugger command line, enter attach /path/to/zope/instance/Products/MyProduct/MyClass.py
13. After a short pause, the debugger will display the current state of your code, and the source code in the editor will jump to your breakpoint.

At this point you can step through the code, inspect variables and objects, and everything else you'd expect from a debugger. PIDA provides a few buttons (on the right-hand side of the debugger panel) that you can use to step through the code, or you can enter help in the debugger command line for a full list of debugging commands and options.

When you're finished debugging, enter detach in the debugger command line to close the debugger connection.

You can find a bit more information about rpdb2 in the documentation for Winpdb.

Note: you cannot use PIDA's debugger to debug PythonScripts, neither through-the-web nor scripts in your product's skin layers. It's possible to make rpdb2 available to these scripts, and you can set a breakpoint that the debugger will recognize - but when you attach to the script with the debugger, you'll be looking at a blank screen.

Admittedly, this is not as quick to use as pdb, but sometimes a graphical debugger is nice. And it's not as painless to use as the debugger in Wing, but Free is nice too :)

This pretty much concludes the practical part of this tutorial - but don't stop reading yet. If version numbers mean anything, PIDA's only halfway done, and it has still got a few problems...

If you've followed along this far, I think you'll agree that PIDA can be very useful for Plone product development. But, it's not a completely mature product, so expect a few glitches here and there. Here are a few that I've encountered:

• As I mentioned in Getting Started, PIDA's emacs integration didn't work for me. To be honest, I've only had emacs installed for two days. I don't know much about it, and there may have been something in my configuration that was getting in the way. If you need emacs in PIDA, these instructions may help.
  
• You cannot dismiss the debugger once you open it - the panel stays visible no matter what you do. I think this might be fixed in PIDA SVN.
• On my system, PIDA would sometimes not exit cleanly, forcing me to kill the process. This was particularly noticeable after using the debugger.
• Even after an apparently clean shutdown, PIDA sometimes leaves leftover processes running on my system. Usually it's a pida process and a svn process.

Disabling the debugger plugin seems to solve the last three items, so a simple workaround is to enable that plugin only when you need it.

So, yes, you may encounter a few warts, but in my experience, they don't get in the way of normal development. Your mileage may vary, of course.

I really like PIDA's modular approach to bringing IDE components together. Having an actual vim embedded in the IDE may just be The Best Thing Ever. The plugin architecture has a lot of potential for Zope and Plone development - perhaps a better debugger for Zope, or a WebDAV browser to dig around in your site would be a good place to start.

I find that the existing plugin components are functional enough to be useful, but not so smart that they get in the way of Plone development. For example, I recently spent a full day trying to get Eclipse+PyDev to play nice with Zope. After trying every recipe I could find, I always ended up with the same problems:

• PyDev's error checker could not resolve imports from the Products namespace, which caused it to report dozens of errors that weren't really errors.
  
• If you want to use PyDev's SVN integration, your entire project needs to be under version control. This isn't so good when you're working on a single product. I mean, you can set your project root to be the root of your product directory and SVN will work, but...
• PyDev's package explorer isn't fully functional on modules that are in your project root - it will list them, but it won't parse them to let you explore the classes and methods they contain. So, you can have SVN, or you can have a fully functional package explorer, but not both. For me, this sort of defeats the purpose of using an IDE - what's the point, if you can't use all of the integrated tools?
  

I haven't run into any of these problems with PIDA. Its error checker isn't as smart as PyDev's, so it doesn't try to resolve imports, which means you don't run into any problems with the Zope Products namespace. Also, the SVN integration and source browser plugins "just work", regardless of how you structure your project.

After giving up on PyDev, I did spend a little time with Wing IDE and I can't really find fault with it. Wing's out-of-the-box support for Zope is great! If commercial software isn't a problem for you, I highly recommend it. But if you prefer Free software, either on principle or for financial reasons, PIDA is definitely worth a look.

And remember: "PIDA loves you!"