Paver 1.0b1 released

Standard

I’ve just released Paver 1.0b1. This new release adds a fun little feature. A typical setup.py script looks like this:

from distutils.core import setup

setup(name="Foo", ...)

With the new version of Paver, you can now rename setup.py to pavement.py (or run paver -f setup.py) and then do:

from paver.setuputils import setup

setup(name="Foo", ...)

That gets you going quite quickly, doesn’t it? Of course, you’d likely want to add from paver.easy import * and to start making tasks that take advantage of Paver.

1.0b1 includes some other bug fixes, brings back the call_task function (particularly useful for distutils tasks), and makes the help output more consistent.

There’s one more bug on my list to fix (the distutils output is not showing up), and then I need to rework the docs for Paver 1.0.

Update: It occurred to me a bit later that my example above doesn’t work, because you need to call install_distutils_tasks to get Paver to pick up all of the distutils/setuptools commands. However, this will be fixed in rc1.

Paver 1.0a3 released

Standard

I have just released Paver 1.0a3. This has some good refinements on the way to 1.0 final and a couple of nice, new features (the “auto” task and the “pushd” context manager):

  • Added automatic running of “auto” task. If there’s a task with the name “auto”, it is run automatically. Using this mechanism, you can write code that sets up the options any way you wish, and without using globals at all (because the auto task can be given options as a parameter).

  • When generating egg_info running “paver”, the full path to the Paver script was getting included in egg-info/SOURCES.txt. This causes installation problems on Windows, at the very least. Paver will now instead place the pavement that is being run in there. This likely has the beneficial side effect of not requiring a MANIFEST.in file just to include the pavement.

  • the options help provided via the cmdopts decorator now appears

  • pavements can now refer to __file__ to get their own filename. You can also just declare pavement_file as an argument to your task function, if you wish.

  • call_pavement now switches directories to the location of the pavement and then switches back when returning

  • if you try to run a function as a task, you’ll now get a more appropriate and descriptive BuildFailure, rather than an AttributeError

  • paver can now again run tasks even when there is no pavement present. any task accessible via paver.easy (which now also includes misctasks) will work.

  • added the pushd context manager (Python 2.5+). This will switch into another directory on the way in and then change back to the old directory on the way out. Suggested by Steve Howe, with the additional suggestion from Juergen Hermann to return the old directory:

    <span class="k">with</span> <span class="n">pushd</span><span class="p">(</span><span class="s">'newdirectory'</span><span class="p">)</span> <span class="k">as</span> <span class="n">olddirectory</span><span class="p">:</span><br />    <span class="o">...</span><span class="n">do</span> <span class="n">something</span><span class="o">...</span><br /><br />

MichiPUG meeting tomorrow, March 5th

Standard

The monthly Michigan Python Users Group (MichiPUG) meeting is coming up tomorrow! This month, we’re going to do something a little different: sprinting on a project to help out a new coworking space that is being set up in downtown Ann Arbor (see below for the full description from Bob Kuehne).

As usual, the meeting starts at 7PM at SRT Solutions.

proposal for 03/02/09 – Michigan Python Users Group | Google Groups

background:

* a guy named mike kessler is opening a co-working space on main
street, tween washington and huron, in the
old arcadian too space, right next door to (south) vinology. the
space is designed as a place where people
can pop in for a day, hang out, work with other people, get a
permanent desk, host trainings, etc. it’s
going to be pretty cool.

* as part of that, he needed some sort of door lock/authentication
system. i volunteered to put one
together, and it’s coming along fine, from the hardware and
software side. it’s basically a bag of
scripts (python, natch), and some csv files for manager users,
logging, whatever. oh, and a door latch
that gets controlled by the above.

* but from a ui perspective, i know better things could be done, and
this is where you come in.

pug topic/sprint:

* if people are up for it, i’d like to do three things:
* 30m : setup tasks, review / design schema
* 60m : split into groups and build an interactive site to do a few
tasks
* 30m : each group discuss results, demonstrate (10-15m@)

Embarrassment Driven Development

Standard

Googling “embarrassment driven development” (EDD) does not return as many hits as it should. I think it’s a very powerful development technique. I first heard the expression from the Plone guys at PyCon 2006, and Google did turn up this match:

[ArchipelagoSprint] Time to get cracking on Plone 3.0!

Wrt. timelines, I was hoping that we could try to have a “Tech preview” release before the Plone Conference 2006 in Seattle (October 25-27) – I’m going to be on-stage there talking about the exciting new features of Plone 3.0 – and I’d like to not be booed off stage. Yes, this is embarrassment-driven development – as usual. ;)

That’s Alexander Limi illustrating the prime motivator for EDD.

The idea behind EDD is simple: if you have to demo something in front of an audience, and that something sucks, you will move hell or high water to make sure you don’t look like an idiot.

Every product has rough edges and warts, but no one wants a demo to be all warty and to have to say “yeah, I know you shouldn’t have to click to the left of the button, but we just haven’t gotten to that yet”. EDD ensures that, at least for the parts you have to get up and show, the rough edges will be smoothed in time for the show.

I’m going to be practicing EDD leading up to JSConf. I want to be able to show some useful, non-trivial bits of ServerJS work by then.

Paver 1.0a2 released!

Standard

I’m happy to announce that Paver 1.0a2 has been released! And, unlike Paver 1.0a1, it installs (thanks to Greg Thornton for the patch for that!). I’ve been quite busy with other projects over the past month, so I appreciate the help of Marc Sibson and Greg Thornton in making 1.0a2 a nice improvement over 1.0a1.

Paver 1.0 is still for the slightly adventurous, because it has not yet seen testing by many people. Paver is not complex code (and Paver 1.0 is, I think, less complex than Paver 0.8 was), so it’s not hard to dig in if you have a problem.

Assuming nothing major comes up, I expect Paver 1.0 final to be out by PyCon.

Speaking of PyCon, I won’t be attending PyCon this year as I have a lot of other things on my plate at work this time around. Mark Ramm will be doing the Paver talk in my stead, just as he did at PyOhio last year.

Introduction to the Bespin Python backend

Standard

It’s been less than two weeks since Bespin was introduced, and there’s already been an impressive amount of activity around the open source project. There are at least 3 entirely new Bespin servers that I’m aware of.

The current Bespin server that we at Mozilla are maintaining is written in Python and appears in the backend/python directory in the Bespin source. To help people get up to speed with the code, I have created a screencast to help people get started with the Python backend and give them an idea of how the code is set up.

I look forward to hearing your feedback!


Bespin Python Backend Overview from Kevin Dangoor on Vimeo.

Creating a web framework with WSGI video

Standard

Creating a web framework with WSGI on Vimeo

The Michigan Python Users Group (MichiPUG) meeting topic from February 2009, presented by Kevin Dangoor. This screencast video shows us using WSGI components to build up a web framework piece-by-piece.

By the way, for people who are interested in working on the Bespin server, this is the kind of “web framework” that the server is built upon.

Bespin: code in the cloud

Standard

Despite working for an open source company, I have been pretty quiet here about what I’ve been doing in the Mozilla Labs web developer tools group. No more. We’ve gone public!

Mozilla Labs » Blog Archive » Introducing Bespin

Bespin proposes an open extensible web-based framework for code editing that aims to increase developer productivity, enable compelling user experiences, and promote the use of open standards.

I started working on Bespin as soon as I joined Mozilla, hitting the ground running with a new Python server. Ben and Dion had already done a lot of work and experimentation on Bespin prior to joining Mozilla in December, so I must confess that I am still fairly ignorant about the Canvas-based magic that they’re doing in the UI. But, Bespin has an architecture that lends itself well to selective ignorance: the server provides a RESTful API, and the client is responsible for all of the presentation. For their part, Ben and Dion have been able to be blissfully ignorant about the inner workings of the Python server.

Of course, I’m not a JavaScript noob and have done some work in the client, but my focus has been the server. Now that we’re out in the open, you can definitely expect that we’ll be talking more about how things work and how you can bend Bespin to your will. Bespin is honest to goodness open source (MPL-licensed), so it becomes an open and collaborative effort starting right away.

The initial reaction has been fantastic. There are tons of people hanging out in #bespin on irc.mozilla.org, and the mailing list has grown to a couple hundred members already. Thanks to everyone for jumping in with your thoughts and patches!

Here’s some of the coverage:

Dion’s post at Ajaxian:

From Dion’s personal blog:

Foolish chaps and companies have come to me in the past thinking that open source will be a silver bullet for “getting other people to do our work.” Those that have been involved in open source know that it isn’t the case. It is often more work. But, it is worth it.

From Ars Technica:

The project is still at an early stage of development and there is clearly a lot of work to be done before it will be able to deliver the same practical value as existing desktop editors. Despite the limitations, it shows an enormous amount of promise and has the potential to eventually deliver a user experience that rivals even the best text editors.

From Five Questions with Dion Almaer:

Now the browsers are moving fast again and building a first class platform for us to develop, the Open Web Platform. Instead of getting bogged down thinking about what IE 6 gives you, take some time to think about what you could build with the latest technology. I realise that you have to be pragmatic and get things working with your audience, but browsers are changing, and so are expectations.

From What Mozilla’s Bespin Bespeaks (ComputerworldUK):

You can see that Bespin is ticking all the Mozilla boxes, but what’s also striking is that this is a Web-based project: Mozilla is entering the cloud. It’s a further shift to viewing the Web as a platform for doing, well, just about anything. Clearly, against that background, open standards are even more important. And not only for the code: another issue that Mozilla will need to start addressing publicly is that of open data. As more stuff moves into the cloud, it become imperative to establish minimum standards for access to the data that is held there. I look forward to hearing Mozilla’s views on the subject.

While I certainly don’t speak for Mozilla, I would be extremely surprised if there’s anyone at Mozilla that believes that users should have anything less than full access and ability to take their data with them. There can be technical issues involved in providing the data, but the data should be available in some reasonable form. Bespin, for its part, makes it easy to export a project in a tarball or zipfile.

I was surprised to see Bespin covered even on Lifehacker:

Primarily, Bespin is a text editor—the kind you’d use for editing code or managing text-based todos. Using Bespin, developers could collaborate on projects through a unified interface (that still supports plugins!) no matter where they are—so long as they’ve got a browser.

cnet has the story, too:

For example, what about integration with open-source software repositories? If it’s flexible enough, Bespin could essentially act as a source code viewer that repositories such as SourceForge or Google Code could employ.

A nice writeup on the ReadWriteWeb as well:

It’s clear that a great deal of thought and attention went into this early version – and it’s a safe bet that it will only get more impressive as time goes on.

RWW last month surprised me with their coverage of me joining Mozilla.

I’m having a great time at Mozilla so far, and it’s great to be out in the open working with so many people now on Bespin and ServerJS.

Paver 1.0a1 recalled

Standard

It turns out that both pip and easy_install have trouble with the Paver 1.0a1 package. I’m going to look into that, but in the meantime I have removed the Paver 1.0a1 tarball from the cheeseshop so that people don’t accidentally get it. Sorry about that!

As a side note, it is unfortunate that easy_install and pip both will pick up alpha and beta releases in preference to release versions. I would think that a nicer default would be to prefer the current release version unless there’s a flag saying “give me the test release”.