Free ZODB!

I am a big fan of ZODB and use it standalone (without Zope) on many projects of mine. One of the things I miss, is a community around it. I don't care much about Zope (though I admire it as a project) and have not being able to find a ZODB focused community. Is there one?

I think ZODB is a great product, the best Object-Oriented database for Python. It's a shame it does not have an active and vocal user community. Maybe ZODB has been eclipsed by Zope for too long. Zope is a cool project, but ZODB could appeal to a much wider audience than just web application developers.

Everytime I start a new application based on ZODB, I think: "what if the ZODB developers stop developing it...", "What if I find I serious bug or limitation in it, and can't motivate (or contact) the developers to fix it...".

I think many people abandon the Idea of using ZODB in their projects, because they can't identify a strong community interested in issues outside serving Zope applications.

Yet, ZODB has been alive for such a long time, feeding on the leftovers from the Zope community...

Isn't it about time ZODB is emancipated into a project standing on its own merits (which are many) and attracting its own community?

New release of Epigrass coming soon!

I have finally found a justification to work on Epigrass again. I am publishing a paper on it and I want to have a fresh version out by the time he paper goes to press. It was a good thing since my wish list for the next release was becoming too long.

So here are the the things I have done so far and some I expect to get done before the new release:

• Port to Qt4: Done. Not as hard as I suspected it would be. Now it will be possible to install it on Windows. I also did a lot improvements on the GUI, such as fixing bugs in the layouts, managed to figure out how to update the GUI (progress display) while the model was running, etc.
• Wrote a GUI based .epg editor. Models are defined in Epigrass through a configuration file which is parsed by the ConfigParser module. To minimize the chances of users messing up the syntax of the file, I cooked up a configuration editor from scratch, which can be run independently of Epigrass to create an edit the .epg files.
• Real-time visualization window: Partially written. I am trying to put together a map animation of the simulation which would run on a separate thread using Pyglet OpenGl interface. I am currently trying to figure out how to do OpenGL viewport auto-resize, so that I can load different maps and have they fit the window. If anyone knows how to do that, please tell me (I am learning OpenGL as I go).
• Update Epigrass's KML output to generate time-animations of the map: Planning stage. This will require to generate multiple layers of the map, one for each time-step. I will probably have to generate a KMZ (a zipped version of a KML) instead of a KML in order to keep the file size from becoming very large. Most of the code is done since I will just re-use the KML-generation code, and call the layer generator multiple times, changing the colors of the polygons at each step.
• Re-write the simulation scheduler to allow the parallelization of the simulation via parallel-python (PP): Planning stage. the coding part will be easy, but I expect a lot of debugging to deal with all the dependency code which needs to be declared when creating the separate jobs with PP. Moreover, I have no idea if I will stumble on unpicklable stuff. I just hope that if I do, I can find a way around the problem.
• Revamp the setup.py, to conform with the latest version of setuptools. It's been broken for a while...
• Maybe try Pyinstaller to release single file executables, and avoid dependency hell, at install time. Many dependencies are not easy_installable yet...
  

So... these are the main things I want to have working for the next release. It's a tall order for a single developer with a lot of other stuff to do before the year's end. If get to pull it off for the next release, it may be worth a 2.0 version upgrade. One thing I will leave for a future release though: Implement support for ZODB and Durus as Backends.

The Wonders of Pyglet

I have been playing with Pyglet, and I am very happy with it. it's still in alpha, but is developing fast and the alpha is already very stable.

The most important feature of Pyglet is that it's being designed from the ground up to be OS independent (Linux, Win, OSX) without external dependencies. For that, it uses the standard OpenGL implementation of each of these platforms via ctypes. This makes it my last best hope for a multi-platform graphical interface kit.

It already has a growing widget library, support for layout of html documents, import 3d models created with wings3d, a scene 2d module with support to sprites and collision detection, and a lot more. Most of these functionalities are available only in the SVN version. The (stable) release is somewhat more limited.

Go check it out! it is (IMHO) one of the few truly exciting graphical libraries in the python scene.