OpenCore Software

A decree from the release manager:

Until further notice, we will use the common three-component major.minor.patch version numbering scheme, as popularized by Apache and many other projects.

• Major releases (e.g. 1.0.0, 2.0.0) indicate major featureset milestones or large backward incompatibilities.

  Our major release number will remain 0 until further notice (i.e. until we figure out WTF a 1.0 release would mean).

• Minor releases (e.g. 0.12.0, 0.13.0) indicate new features.

  Minor releases may also require data migrations and will generally also include all the bugfixes since the previous minor release.

• Patch (aka “point” or “micro”) releases (e.g. 0.12.1, 0.12.2) may only contain bugfixes, and must be 100% backward compatible.

  No new features are allowed in a patch release. No data migrations may be required by a patch release except as strictly required for a critical bugfix, in which case I might decide to bump the minor version anyway.

You might notice with this policy that minor numbers will get bumped quite often. That’s okay. There’s nothing wrong with numbering a release eg. 0.87.0, except that it would strongly suggest a need to re-evaluate the 1.0 milestone

This is basically the same numbering scheme that we’ve had since we broke out of the infinite 0.9.7.x loop. The main difference is organizational - one person (me) will be paying attention to keeping it consistent. That was the only real problem with Ethan’s previous plan.

This past Tuesday I attended the NYC Python User’s Group meeting at the offices of DayLife.

The presentation this week was by Peter Fein about GrassyKnoll, a text search engine written in Python.

From TOPP’s point of view there are several interesting things about it:

• It could provide us with a sitewide search solution for openplans.org and livablestreets.com.
  
• It can use any of a number of pluggable back ends (notably PyLucene).
  
• You interact with it entirely via a simple REST API.
  
• A GrassyKnoll client can also trivially be a GrassyKnoll server. (Peter gave a live demo of this.) In theory this could allow for fun things like smart clustering, where one server gets your query and dispatches queries to N other servers, and then merges the results appropriately. The end client still sees the same simple rest API.
• It’s written entirely in Python and is Free.
• They’re looking for more people to help out and would love for us to get involved.

The major down side is that they’re still some months away from a production-ready release. (There were a few glitches in the live demo.) When I pressed him about this, Peter said “definitely by the end of the year.” I got the impression that more hands helping would speed that up.

Also, it doesn’t define any kind of common query language; it just passes them along to the back end. So you do have to know what you’re really talking to.

Peter said he was hopefully coming to the next NYCPUG meeting that we’re hosting here at TOPP on July 15.

Robert and I have been working on the opencore feeds. Currently, these are only used by the project summary page, but looking at the site, we have many things that could be feeds: Latest Projects, Latest Members, Recently Updated Projects, just to name a few. This blog post is sponsored by the word ‘agnostic’, where agnostic means “optimistically not incestuous code” and “incestuous” means “code that unfairly presumes coupling or functionality that destroys perceived modularity and forces binding to a framework even when the desired functionality should not depend on the framework”. Okay, those are just words. The idea is that incestuous code is badly coupled code. Its a word I use alot to describe code I don’t like, because something can (perhaps wrongly) be described as modular but be completely incestuous. Agnostic is the antidote (and the antonym) to incestutous.

Sorry for that gratuitous introduction. The point is that I think what we did with feeds is not a bad model:

[So I tried to upload this image through wordpress’s xinha.  Of course, horrible things happened, so now I’m just linking to it.  GUIs are my bane; did i mention I’m now editting this in html mode, as I almost always do, even though basically i want text ]

This is a horrible diagram with symbolism that only makes sense to me. So let me describe. You have a bunch of content (projects, mailing lists, etc) that provide feed data. They may provide feed data in more than one way, but that’s another story. Instead of having the wild west, I make an interface called IFeedData that forces the feed in the standard format. In this way, I have decoupled what the feed comes from from what a feed is. IFeedData (and its items) have some things that are mandatory to define — the essence of what a feed is — and what is optional.

Moving further right on the chart, there are a bunch of templates. Any of these templates can be used to render any feed. Some of them will work better with particular type of feed than others — for instance, if the feed doesn’t have icons, the portrait_feed_snippet.pt is pretty silly; but each can render the basic functionality of “what a feed is”, and may support optional items, conditionally displayed if they exist. To extend functionality, add a new template.

So we have feed providers, which give us feeds, and templates, which display feeds. How are they used?

So we have this viewlet manager, which has a bunch of viewlets. The viewlets have some sort of context which gets adapted to give a feed. The viewlets *also* have something that says “use *this* template”. In other words, the viewlets decide how the feed is displayed.

I’m not writing this to say “ooooh! look at this cool pattern i helped make!” I’m writing this as an illustration of how something that isn’t (amazingly) incestuous can work. Notice you have decoupling on every level. You have content providers which have rules to transform them to feeds. You have feeds, which have various templates that can be used to display them. You have viewlets, which contain the display logic, tell how to adapt their context to the feed, and choose the template. On top of that, its a simple system: abstract enough to handle anything I can imagine atm, but concrete enough to actually use.
There are problems going forward that I haven’t conquered yet, but I am at least comfortable with the pattern.

1. If you are running python that was not compiled with readline (e.g. Mac OS X system Python), you may first have to run the following:

sudo easy_install -f http://ipython.scipy.org/dist/ readline 

2. Create a file in your home directory named .pythonrc.py
3. Add the following lines to it:

import readline, rlcompleter
readline.parse_and_bind('tab: complete')

4. Set your PYTHONSTARTUP environment variable to point to this file on shell startup, e.g.:

$ echo 'PYTHONSTARTUP="$HOME/.pythonrc.py"' >> .bashrc

5. Prosper.