Inside the Launchpad Foundations sprint
I’m in Montreal this week, with the rest of the Launchpad Foundations team and a few other Canonical engineers. We’re preparing for the open sourcing of Launchpad by doing a lot of refactoring, so that when the code is released in July it will be more comprehensible, and reusable in projects other than Launchpad.
In addition to our main body of Launchpad code we’ll be releasing a framework project called LAZR. Code that’s not Launchpad-related will go into LAZR or one of its subprojects: lazr.config, lazr.uri, lazr.batchnavigator, and so on. These will be little libraries that can be reused in other projects.
For instance: underneath the Launchpad web service is a generic library that lets you create a web service from your existing data objects by annotating the Zope interfaces. All this code lives in LAZR: the only web service code in Launchpad has to do with Launchpad’s web service specifically. We’d like you to reuse the LAZR webservice code in any project that uses Zope interfaces to describe its data objects.
Unfortunately, there’s a lot of code in Launchpad that really should be in LAZR. If that wasn’t bad enough, the web service code in LAZR is full of dependencies on that Launchpad code. At the moment, you can’t run the LAZR web service code without bringing in all of Launchpad.
The object of this sprint is to refactor this code and move it all into LAZR packages. Our medium-term goal is a working example web service (code name “Sharks”) that uses no Launchpad code, but it won’t stop there. The more utilities we can move out of Launchpad’s monolithic code base, the more likely it is you’ll be able to find a bit of code you want to reuse.
March 3rd, 2009 at 5:53 pm
So, LAZR will only require zope.interface, not Zope itself, right?
March 9th, 2009 at 4:42 pm
LAZR has a number of subprojects. Some of them (like lazr.uri) are utilities with no dependencies at all. Others will have one or more Zope dependencies. The web service code (lazr.restful) will depend on at least zope.interface and zope.schema. It might depend on all of Zope at first, until we can do some refactoring. I’m not sure.
April 29th, 2009 at 9:32 pm
[…] last time I posted to this blog I was describing a sprint in Montreal, where we were working on refactoring the web service code and moving it from Launchpad to a […]