Paver 1.0a1 is out

I have just pushed Paver 1.0a1 up to the Python Cheeseshop. This is very much an alpha release, so beware. That said, I’m successfully using it in my own projects and have been for some time.

I have significantly changed the way Paver works, and I think the new structure is simpler and more flexible because it is no longer tied to distutils. In fact, Paver’s task running capability is in paver/ and that module could conceivably be used standalone. And, the namespace of tasks is not muddied with a bunch of distutils tasks if you’re making a pavement for some other purpose.

But, the distutils/setuptools integration still exists and is easy to turn on.

Paver 1.0a1 has a handful of useful new features, including the ability to run separate sub-pavements (in the same process, no less).

The docs on the Paver site are still for 0.8, and I will leave it that way for now. When you install Paver, you can run “paver paverdocs” to see the docs for the version of Paver you are running.

Please report any bugs you find either to the googlegroup or directly to the tracker at googlecode.

Thanks to Marc Sibson, Bryan Forbes, Juergen Hermann and others who have contributed to this release.

WSGI goodness spreading to other languages

In Python, we’ve been enjoying the convenience of mixing and matching various things that follow the WSGI convention for a while. More recently, Rack brought those good features to a very similar interface for Ruby. And now I see:

Jack: Rack for JavaScript

echo “Rack provides an minimal interface between webservers supporting Ruby and Ruby frameworks” | sed -e s/Rack/Jack/g -e s/Ruby/JavaScript/g

Jack comes from Tom Robinson, one of the developers of Cappuccino/Objective-J.

Moving to a new Mac: everything but Python

With my new job comes a new MacBook Pro (the latest generation, very slick!). The Setup Assistant did a great job of making my new MBP just like my old one, carrying across all of my applications and settings from my latest Time Machine backup. Everything in /usr/local/bin made it. Ditto for my MacPorts stuff in /opt.

One thing that didn’t make it was the Python libraries that I had installed in the system-wide site-packages directory (/Library/Python/Version/2.5/…). The Setup Assistant is designed to not pull OS parts across when you are loading up a new machine. That makes sense, but unfortunately the Python stuff seems to fall into that category.

Perhaps the site-packages directory should be moved to /usr/local or something so that it gets copied over? A change like that would be useful for Apple to make.

Thankfully, the impact on me is pretty minimal, because I tend to do my work in virtualenvs and don’t have very many packages installed system-wide.

Making custom web frameworks with WSGI

At the next Michigan Python Users Group (MichiPUG) meeting, we’ll be talking about building custom web frameworks using WSGI bits and pieces. I’ve done this a couple of times now and think it’s a powerful and straightforward approach that works well for certain kinds of projects.

I’m figuring we’ll take a look at some available components and glue stuff together to build a framework during the session.

As usual, the meeting is the first Thursday of the month (February 5th, in this case) at 7pm at the SRT Solutions office in downtown Ann Arbor.

Build desktop apps with web UI and Python

The next release of Appcelerator Titanium (PR2, due January 23rd) is slated to include support for Python and Ruby!

Titanium is a completely open source competitor to Adobe AIR. It lets you build installable desktop applications that build their GUIs via a built-in WebKit renderer (in other words, you can use HTML/CSS/JavaScript to build a GUI, just like you do on the web). The next version of Titanium is going to include support for Python and Ruby, which means that you can use something other than just JavaScript for creating your desktop apps.

I haven’t built Titanium yet to see how it works (script type=”text/python”?), but the fact that they’re working on this is very interesting.

Making web development suck less

We make shitty software… with bugs!
old Living Videotext slogan, as reported by Dave Winer

I love that quote. On the surface, it sounds disparaging about the software you have today, but it’s actually more of a statement of hopes for the future. The status quo, in fact every status quo, is less than ideal. It’s great to be proud of your products and where you are, but it’s even more important to keep in mind how much more there is to do.

Early in my career, I worked at the ANS Network Operations Center. ANS ran the original NSFNet and provided internet and dial-up connectivity for America Online, as well as a number of large companies and research labs. We had the internal slogan “we suck less”, and it was the same idea as the “we make shitty software” quote. At ANS, we did suck less than our competitors. But, every time a customer’s connection was down we knew we had work to do to make things even better.

I’ve been doing web-based software development for a long time, and the tools for creating web-based software have improved tremendously. Server side frameworks like Rails, TurboGears and Django have made writing typical server side code far easier. Client side toolkits like Dojo, jQuery and Prototype/Scriptaculous have made creating better client experiences even easier. And tools like Firebug have made it much easier to debug an application and tweak its appearance on the fly.

But, developing compelling web-based applications still sucks. Its still more work than it should be in the ideal case. I’m sure that the people working on all of those tools, and all of the competing tools, all have ideas on how to make things better and will all be pushing the state of the art forward and removing a bit of suckyness with each release.

I’m delighted to say that starting today I am working with Ben Galbraith and Dion Almaer at Mozilla Labs on web development tools. I’ve been a reader of Ben and Dion’s Ajaxian site for years and I know how much thought they’ve put in to making webdev better, so I’m really excited to be joining their group. And Mozilla looks like a fantastic organization to be a part of.

It’s still a very new group, but you can bet that every day I’m going to be thinking about how I can help make web development easier, faster and better.

Dinner Tuesday @ PyWorks?

My flight to PyWorks arrives around 6:20pm on Tuesday, and I anticipate needing dinner after I get to the hotel. Anyone want to meet up for dinner there?

Update: I may not be coming in on Tuesday after all. We’ve got some illnesses going around in the family, so it’s looking like I’ll come in on Wednesday.

Update 2: I’m coming in today after all.

Google App Engine Hack-A-Thon Ann Arbor 11/17

I started the ball rolling on this a few weeks ago, and I’m thankful that some folks picked up that ball and ran with it. I’m reposting Matt Simmons’ announcement here:

The Michigan Python Users Group (MichiPUG) in conjunction with Google are happy to present: Google App Engine Hack-a-thon: Ann Arbor

What: An App Engine developer event for Google App Engine!

  • Learn about Google App Engine: We will have talks on the major features of Google App Engine at different points throughout the day. We will run through developing an app with the SDK and show you how to deploy and manage applications on Google App Engine.
  • Build With Us, or Build Your Own: You are welcome to bring along anything you can prepare ahead of time (sketches, designs, web page mock ups, etc.) and use the time and information provided to develop your idea into a working application, then share it with the world. Or, you can code along with us in building a Google App Engine application from start to finish.

Who: You! Your ideas and your enthusiasm complete the mix. We will assume some basic skills and preparation for the event, including an
existing knowledge of the Python programming language. We’ll provide power, copies of the SDK, and an awesome ambiance. Just bring yourself and your laptop. Some light snacks and beverages will be available, as will a pizza lunch. If you decide to bring extra food, please make sure it is computer friendly. 🙂

When: Monday Nov 17th, 2008 10AM-6PM

Where: Google’s Ann Arbor Office: 201 S. Division St. Ann Arbor, MI 48104

You can read more about previous hack-a-thons at the AppEngine blog

RSVP for the Ann Arbor event with the link below.

Looking forward to seeing you there!

Changes coming to Paver

Paver is the Python-based build tool that I released several months ago. It uses a Rake-like approach; you create a .py file that is filled with “tasks” which are basically just functions that can be invoked from the command line. Paver has largely been focused on automating Python projects.

Last week, I got together with Marshall and Matt from Zattoo. They’ve been working on a tool called pytoss which is focused on deployment. There are two parts to pytoss: the library and the “tool”. The library is being broken out into a new project called CloudControl, and it provides all kinds of high-level, handy deployment goodies on top of Paramiko. And it’s liberally licensed.

There’s a lot of overlap between pytoss’ tool component and Paver. So, we got together to see what we can do about that. The two approaches were already quite similar. There are a handful of small differences, and I like some of the pytoss approach. At a high-level, here’s what’s going to happen:

  • the pytoss tool part will go away
  • Paver will become less Python project-specific (but won’t lose the Python project-specific features it has)
  • the small bit of magic that Paver has will go away
  • Paver will add some optional support for CloudControl for deployment
  • Paver will also inherit some nice features like the easy ability to run sub-builds (build other Paver-based projects)

These are just the changes that are in store based on the pytoss integration. There are some other cool features that I have in mind.

I have also decided to move Paver from Launchpad to Googlecode. I find Launchpad to be far more confusing, especially for a small project like Paver. Additionally, bzr’s svn plugin appears to make it so easy to sync with a central server that there’s no reason to make everyone use bzr. Those who want to, can. And those that are used to svn can use svn.

Paver’s official homepage is unchanged, there’s just a new project page, bug tracker and source control URL.

A big thanks to Matt, Marshall and Jonathan for CloudControl and for helping out with Paver!