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.

9 Responses to “Paver 0.7: Better than distutils, better docs and much more”
  1. Martin says:

    Interesting initiative!
    There are some strange errors on that foreword page. Have you seen that btw?

  2. number5 says:

    Error occurs when installing paver via easy_install:

    File “/var/folders/Hc/Hcm9A6h6GGW39zZ3SL1nP++++TI/-Tmp-/tmp6O5U2w/paver/defaults.py”, line 4, in
    ImportError: No module named misctasks

    seems some dependancy not met?

  3. Kevin Dangoor says:

    number5: I have just uploaded Paver 0.7.1 to fix that. I should try to make an automated test for that.

    Martin: actually, I did notice that, but I needed to get to sleep. Now that morning is here, I’ve fixed it.

    Thanks for the bug reports, guys!

  4. Jim Jones says:

    Thumbs up Kevin, this looks promising.

    Just one note: Don’t forget about the new users. Your docs currently presume a lot of knowledge about setuptools, what’s missing are docs that work for someone who is about to package for the first time ever. I’d suggest to create a simple tutorial that describes all steps for an artificial or even a real project. That way you can appeal to newcomers who’d otherwise be forced to learn setuptools first before they can get going with pavement.

  5. Kevin Dangoor says:

    Hi Jim,

    You’re absolutely right. To some extent, I’d rather *not* appeal to those folks just yet. Once Paver has a few more experienced users, a doc like the one you’re suggesting would be ideal.

  6. Paul says:

    Very cool. I look forward to following your progress.

    FYI: There are a lot of Cog directives showing up as literal text in your docs right now!

  7. Kevin Dangoor says:

    Actually, there are a couple theories of thought regarding keeping include directives in the final docs. If you read Bruce Eckel’s books, you’ll find comments that show where the sample comes from. That’s the value of leaving those in… they tell the read where they can find that sample.

    I don’t think I have the option in there right now, but it will be easy to add the option that allows you to have Cog remove the generator code. I certainly agree that there are cases where you wouldn’t want the generator code to show up.

  8. Jim Hefferon says:

    Maybe I missed it; can you pull the materials to be installed out of a repository?

    That is, in addition to saying “put this file from the code tree there”, can I say “get the code tree from version 3.1.4.2 inside the Mercurial repository”?

    Jim

  9. Kevin Dangoor says:

    The short answer is that you can do anything by using the sh() function. That’s how I currently pull some things out of svn (I don’t much like externals, so I manually control an svn checkout/update)

    The longer answer requires context. Are you just saying that in some random task you want to pull things from a repository? easy_install can pull from a repository (svn on its own, and I believe bzr if you have a plugin for it)

Leave a Reply