Blue Sky On Mars

I tend to watch the Unofficial Planet Python rather than Planet Python. The Unofficial Planet Python was only getting my Python feed, which is good. The official one, however, is getting everything. I’ve asked for this to be changed, so hopefully soon the official Planet Python will only be listing my posts that are actually related to Python.

To make matters worse, WordPress seems to have decided that it doesn’t want to email me the comments that were showing up on my del.icio.us and Twitter posts. Ugh. Thanks to Virgil Dupras who contacted me via other means to let me know about the quite reasonable backlash.

Sorry for reducing the signal to noise ratio on Planet Python! This will be fixed soon.

Finally, a note about cross-posting Twitter to Blue Sky On Mars. My initial rationale for doing so is that I’d like to have all of my presence on the web routed to this site so that my data is ultimately in my control in some fashion. After having used Twitter a bit, and certainly seeing the “half a conversation” aspect of many of the posts, I don’t actually want my tweets posted here. So, I’ve turned that off.

Posting my del.icio.us links here has value, and I’ll keep doing that. They just won’t show up on Planet Python once my feed URL is changed there.

The Michigan Python Users Group (MichiPUG) monthly meeting is coming up this Thursday, July 3rd at 7PM. This month, I’ll be speaking about the Zope Object Database (ZODB). Unlike last month’s meeting, where I led us in a random experiment with Google App Engine, I actually have some experience with the ZODB.

I’ll be demonstrating use of the ZODB and will talk about concurrency, replication, packing, etc. If you’re not familiar with the ZODB (and you’re somewhere near Ann Arbor!), this is a useful topic to get to know, because the ZODB is great for a variety of situations.

Sorry for the noise.

Anyone who runs a significant open source project should read this, especially if you don’t currently require your contributors to send in any kind of agreement:

So why have it? Why create the barrier to entry for newcomers who just want to pitch in? I have great sympathy for the impatient potential contributor huffing “why do I need to sign this, anyway?”, so this blog post is an effort to boil it down.
[From “Why Do I need To Sign This?”]

I’ve spoken with Alex a couple of times about open source intellectual property, and he’s definitely given this a lot of thought. For a project the size of Dojo, involving many very large contributors, having something like Dojo’s CLA seems critical for keeping the IP clean.

With TurboGears, from the beginning, I’ve required people to send in a simple contributor agreement and this sums up why: “One of the best aspects of the CLA process is that it gets people who are contributing to think about what it means to contribute.”. Significant open source projects that people depend on need to have contributors that are serious about maintaining the project’s quality and the project’s IP. Making people aware of this responsibility from the get-go is a big positive.

I’m posting this in hopes that more of my friends in open source software will keep these things in mind as their projects grow and the outside code contributions increase.

My latest substantial blog post is now up: SitePen Blog » Easy, Repeatable Building/Deployment of Python+Dojo Projects

Dojo on the client and Python on the server make for a great combination. They’re easy, productive and powerful. In this article, I’ll show you how to use Python + Dojo to cut the number of requests to your server by 95% and simplify development and deployment while you’re at it.

We’ve settled on a topic for the coming Michigan Python Users Group meeting: Google App Engine. We do not have a speaker, so this will be a combination of discussion and exploration. I have written some App Engine code, and I’m guessing that others that will be attending have, too, so it’s not all trial-and-error.

Following our usual formal (first Thursday of the month), the meeting will be on June 5th at 7PM at SRT Solutions in downtown Ann Arbor. There are parking structures nearby (4th and Washington and Liberty Square are both close), and there is usually free street parking on Ann Street near the police station.

See you there!

Justin Davis has just announced that Christophe de Vienne is the new maintainer of the TurboGears Web Services (TGWS) project. Thank you Christophe for carrying this project forward! I consider it a good sign for a project’s health when it can make the transition between maintainers, which is something both TurboGears and TGWS have done.

TGWS, if you’re not familiar with it, is a multiprotocol web services extension for TurboGears 1.

For various reasons, I released Paver 0.7.3 on Friday and Paver 0.8 yesterday. I have an idea of what the coming 1.0’s zc.buildout integration will be like, and I think it will be quite cool and useful.

In the meantime, though, I’ve got some new features that set the stage for things I need to do in 1.0. Specifically, you can now pass in a dictionary in your options search ordering. So, you can pull options from any source you’ve got at the time the task is running and stick them at the front of the line. I expect to use this in buildout options handling.

A nice new feature is the ability to set options on the command line. You can do something like:

paver some.option=hello task1 some.option=goodbye task2

Doing that, paver will set some.option to hello, run task1 and then change the option to goodbye before running task2.

The new cog.include_markers and cog.delete_code options allow you to remove Cog’s markers from the output and instead put a nicer bit of text to say where the snippet of code came from. Letting the user know where a sample code snippet came from is quite valuable, so I want to make it possible to do so in as pleasing a way as possible.

For Paver’s Getting Started Guide, I ended up not using the new include_markers feature and instead just changed the Cog delimiters. I did this because Paver runs shell commands in addition to including file sections when generating the docs. I wanted those shell commands to be included. I think the new markers are more pleasant to look at, and I’ll be curious to get feedback since I heard from more than one person that the Cog delimiters looked like they were left in by mistake.

Paver is starting to get some traction as it has picked up its first patches from outsiders, and I’ve started to get some feedback on breakage from Windows users (fixed in 0.8). Mark let me put Paver into TurboGears 2, and I think it will help out there, so that will introduce quite a number more people to the project. As always, come and join us on the mailing list if you have any questions or problems!

I’m delighted to release Paver 0.7. If you missed my original announcement, the short story is that Paver is a new build, distribution and deployment scripting tool geared toward Python projects. My original announcement and the new foreword to the docs explain the motivation.

Ben Bangert and others pointed out a giant documentation bug in 0.4: there was a fair bit of reference doc but no doc that said “here’s how you get started with Paver”. Now there is: Paver’s Getting Started Guide.

Paver 0.7 is a big step up from 0.4 (hence the version number bump). I implemented one of the two major features I had planned for 1.0: distutils/setuptools integration. It’s really cool. Have you ever wanted to just slightly change how “sdist” or “upload” or “develop” worked? Now you can, just by writing a function in your pavement.py file. And don’t worry, you don’t need to duplicate anything between setup.py and pavement.py. It all just moves into pavement.py and Paver can even generate a setup.py file for you, since most people are use to the common “python setup.py install” command.

I’ve gone even farther than that with making it easy to use Paver and not annoy users that don’t yet have Paver. Paver can create a small zip file of Paver’s core bits so that “python setup.py install” will work just fine even for users who don’t have Paver installed. Paver can also create a virtualenv bootstrap script for you, so that users don’t necessarily need to install your package on their systems in order to use it.

Paver’s got new documentation tools that work great with Sphinx. It’s now easy to mark sections of sample code files and then include those sections in your documentation, using the built-in version of Ned Batchelder’s Cog.

And I’m definitely eating my own dogfood. Paver is built using Paver itself and the source distribution includes the paver-minilib so that setup.py install should work fine (let me know if it doesn’t!) The new Getting Started Guide uses the new documentation tools.

There are even more changes than these, and you can look at the changelog for the full list. Note that if you’re using Paver 0.4, there are a couple of trivial breaking changes.

Seeing this on Bob Ippolito’s blog might seem a little odd to many:

Rewrote test suite with unittest and doctest (no more nosetest dependency)
[From simplejson 1.9]

Why on Earth would someone change from nose-style tests to unittest tests? How about so that the library can go into the Python Standard Library?

simplejson will be a great addition. Thanks to Bob and the others who are working to get simplejson in!