You are here: Home Articles Hello Good-Py: A Known Good versions manager
OpenID Log in


Hello Good-Py: A Known Good versions manager

by Martin Aspeli last modified Apr 28, 2009 12:42 PM

And an experiment with Google App Engine

In my previous post, I hinted that I'd been playing with Google App Engine. The result of that is an application I've called Good-Py, for lack of a better pun. You can find it here.

The Good-Py front page has some documentation about what it is and how it works, so I won't repeat that here. However, briefly, it is a way to manage the types of "system release" buildout cfg files that we now use in Plone releases, with a [versions] block listing a "known good set" of versions.

I created it in part to be able to play with GAE, but also because and publishing known good sets of versions is quite painful. Good-Py is open ended and has a very simple security model that means it can be used to manage many systems and versions. If you are interested in using it, drop me an email and I'll set you up an account. It's still a bit rough, and has zero tests, but probably works some of the time. :) You can check out the source code here. This will run with the GAE client side environment if you want to test. If you want to manage your own known-good set, I suggest that you ask me for an account on Good-Py rather than deploy your own instance, though. The system will be more valuable the more "known good" versions are managed there.

Good-Py works with two principal entities: systems, such as 'plone' or 'dexterity', and versions of those systems, e.g. 3.3 or 3.3rc2. For each system/version combination, it maintains a list of predicates form which the known good set can be calculated. There is a minimalist (read: ugly, user-unfriendly) admin GUI to manage systems, versions and predicates.

The available predicates are known-good, which means that we know a given version of a particular dependency works with this system, known-bad which means that we know a particular version or range of versions (e.g. zope.component <=3.4,>3.2) is known not to work with the system, or extends, which means that a particular version of a particular system should inherit all predicates from another system/version.

When you request a versions block, you can specify one or more platforms that you want to ensure you stay compatible with. A platform is just another system/version combination. Good-Py will ensure that no version conflicts with a known-bad predicate in any specified platform or any system/version extended by that platform.

Good-Py then calculates the most recent known-good version for each dependency that does not fall foul of any known-bad specification and generates a versions block, such as this one. If you want to be completely sure you do not include any known-bad versions for Plone 3.3rc2, you could try this URL instead.

Is this a good approach? I don't know. It'd be nice if it wasn't buildout-specific, for starters, and it'd be nice if setuptools had the ability to let packages declare "I am supported on this platform", which would remove the need for much of this. Still, I think it'll be useful, and I certainly plan to use it for the not-too-far-away 1.0a1 release of Dexterity. Stay tuned!

Document Actions
Sponsor message

Finding a good business opportunity and then finding the companies which provider web site design along with search engine marketing is almost impossible if you are new

Plone Book
Professional Plone 4 Development

I am the author of a book called Professional Plone Development. You can read more about it here.

About this site

This Plone site is kindly hosted by: 

Six Feet Up