Paver is now on GitHub, thanks to Almad

Paver, the project scripting tool for Python, has just moved to GitHub thanks to Almad. Almad has stepped forward and offered to properly bring Paver into the second decade of the 21st century (doesn’t have the same ring to it as bringing something into the 21st century, does it? 🙂

Seriously, though, Paver reached the point where it was good enough for me and did what I wanted (and, apparently, a good number of other people wanted as well). Almad has some thoughts and where the project should go next and I’m looking forward to hearing more about them. Sign up for the googlegroup to see where Paver is going next.

Paver: project that works, has users, needs a leader

Paver is a Python project scripting tool that I initially created in 2007 to automate a whole bunch of tasks around projects that I was working on. It knows about setuptools and distutils, it has some ideas on handling documentation with example code. It also has users who occasionally like to send in patches. The latest release has had more than 3700 downloads on PyPI.

Paver hasn’t needed a lot of work, because it does what it says on the tin: helps you automate project tasks. Sure, there’s always more that one could do. But, there isn’t more that’s required for it to be a useful tool, day-to-day.

Here’s the point of my post: Paver is in danger of being abandoned. At this point, everything significant that I am doing is in JavaScript, not Python. The email and patch traffic is low, but it’s still too much for someone that’s not even actively using the tool any more.

If you’re a Paver user and either:

1. want to take the project in fanciful new directions or,

2. want to keep the project humming along with a new .x release every now and then

please let me know.

Paver 1.0 released!

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:

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

    from paver.easy import *
    from paver.setuputils import setup
        author="Kevin Dangoor",
    @needs(['html', "distutils.command.sdist"])
    def sdist():
        """Generate docs and source distribution."""

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


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 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 paver-read-only

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

Paver 1.0b1 released

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

from distutils.core import setup

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

With the new version of Paver, you can now rename to (or run paver -f 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

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

Paver 1.0a2 released!

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.

Easy, Repeatable Building/Deployment of Python+Dojo Projects

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.