Paver 0.7: Better than distutils, better docs and much more

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.

11 Comments

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

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

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

    Thanks for your reply. I’m sorry I didn’t get back to you sooner.

    Here is my use case: I get a bug report from a user. That user has jhPackage version 3.1.4.2. So I want to issue a command that knows how to grab that version from svn (or wherever), and build and install it in /home/jhPackage/maintain/3.1.4.2 . Naturally, I need it to initialize as initialization was done for that version, to lay the files out as the layout was at the time of that version, perhaps to write over apache’s 000-default with the version from the repository, etc.

    So at least some portion of the build system has to live in the version repository, it seems to me, so that it is tracked with the code. But I am also, if I understand you, using part of the build system to pull things out of the repository. I’m confused about that.

  11. When using Paver, you definitely commit your pavement.py files in with your code. The build scripts are most definitely tied to the versions of code.

    If you have code that is dependent on someone else’s software *and* you’re trying to control the installation of that software, you will likely need to tie versions of your software to known working versions of the other. Does that make sense?

    Paver makes it pretty easy to automate just about anything. Once you have it automated, feel free to post that part of your script on the mailing list to see if there’s a better way, or something more Paver can be doing for you.

Comments are closed.

© 2014 Blue Sky On Mars

Theme by Anders NorenUp ↑