Blue Sky On Mars

At long last, I’ve released Paver 1.0. Here’s the announcement that I sent to python-announce:

After months of use in production and about two months of public testing for 1.0, Paver 1.0 has been released. The changes between Paver 0.8.1, the most recent stable release, and 1.0 are quite significant. Paver 1.0 is easier, cleaner, less magical and just better all around. The backwards compatibility breaks should be easy enough to work around, are described in DeprecationWarnings and were introduced in 1.0a1 back in January.

Paver’s home page: http://www.blueskyonmars.com/projects/paver/

What is Paver?

Paver is a Python-based software project scripting tool along the lines of Make or Rake. It is not designed to handle the dependency tracking requirements of, for example, a C program. It *is* designed to help out with all of your other repetitive tasks (run documentation
generators, moving files about, downloading things), all with the convenience of Python’s syntax and massive library of code.

If you’re developing applications in Python, you get even more… Most public Python projects use distutils or setuptools to create source tarballs for distribution. (Private projects can take advantage of this, too!) Have you ever wanted to generate the docs before building the source distribution? With Paver, you can, trivially. Here’s a complete pavement.py::

    from paver.easy import *
    from paver.setuputils import setup
 
    setup(
        name="MyCoolProject",
        packages=['mycool'],
        version="1.0",
        url="http://www.blueskyonmars.com/",
        author="Kevin Dangoor",
        author_email="dangoor@gmail.com"
    )
 
    @task
    @needs(['html', "distutils.command.sdist"])
    def sdist():
        """Generate docs and source distribution."""
        pass

With that pavement file, you can just run “paver sdist“, and your docs will be rebuilt automatically before creating the source distribution. It’s also easy to move the generated docs into some other directory (and, of course, you can tell Paver where your docs are stored, if they’re not in the default location.)

Installation

The easiest way to get Paver is if you have setuptools_ installed.

easy_install Paver

Without setuptools, it’s still pretty easy. Download the Paver .tgz file from Paver’s Cheeseshop page, untar it and run:

python setup.py install

Help and Development

You can get help from the mailing list.

If you’d like to help out with Paver, you can check the code out from Googlecode:

svn checkout http://paver.googlecode.com/svn/trunk/ paver-read-only

You can also take a look at Paver’s project page on Googlecode.

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.

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 />

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@)

For the week of February 23rd:

• Roberto Saccon ported Bespin to Dojo! Dojo leader Peter Higgins helped to clean things up a bit. This has significantly changed (and improved) the use of namespaces in the frontend code, which will make Bespin much easier to drop into other pages.
• For people keeping score at home, there is now a 0.1 branch in the Bespin repository that we will be using to update the server. The default branch has the Dojo work and all of the other forward-looking work going on. Until the trunk work stabilizes a bit, bespin.mozilla.com will be running a bit behind on the changes here.
• autoindent setting. When you hit return/enter you’re placed at the same indentation point on the next line.
• Select an area and hit TAB and it all indents. SHIFT+TAB and it unindents. Thanks to Jay Bird!
• Special support for certain keys so German keyboards etc can get in ‘{‘ and the like. Thanks to Julian Viereck  
• For people following the trunk/tip, the project build script has changed a bit. Be sure to follow the instructions in the top-level README file to get the Bespin server running.
• PHP, Java and Aduino syntax highlighting, thanks to Sean Burke and Olle Jonsson, respectively. The Arduino support is optional. Use include(“bespin.syntax.arduino”); in your config.js to load.
• Multithreaded development server, which speeds up page loads a bit now that there are more modules loading.
• Config work has short cuts now so you can simply use: include(file), execute(cmd), publish(), subscribe() 

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.