正直に言うと私は新たなビルドツールを作りたくなかった。私が Paver を作成した主な理由は...
あなたが繰り返し起こる同じ問題を解決するとき、そこにはパターンがあり、その問題を解決するのにかかるコストを減らす方法はすぐに分かります。あなたは最終的に declarative solution (宣言型の解決方法) に落ち着くことがよくあるでしょう。Python 標準の distutils は宣言型の解決方法です。 setup() 関数を呼び出す過程で、プロジェクトに関するメタデータの宣言、その部品となるリストの提供や使い勝手の良いコマンドラインインタフェースに辿り着きます。そのコマンドラインインタフェースは再配布可能な tarball(setuptools があれば egg) の作成方法やパッケージのインストール、C 言語拡張のビルド等を知っています。
zc.buildout はデプロイのためによく似たことを実現します。システムの部品を宣言し、各部品のレシピ(その独自オプションのコレクションによる各レシピ)を指定して、1つのコマンドで統合システムを構築することができます。
これらのツールは素晴らしいですよね?そう素晴らしいのですよ。これらのツールが提供する機能をカスタマイズする必要がない限りね。例えば、ここにファイルを移動する、そこにディレクトリを作成するといったことが必要になるのは一般的ではありません。それじゃあ?
imperative system (命令型システム) では、必要に応じてコードに数行追加するだけで良いです。
distutils, zc.builout やその他の類似ツールでの答えは通常、問題になるコード周りでどこかからコードをインストールする追加の定型文を実行します。あなたは大きな、十分理解された問題というよりはちょっとした作業のために宣言型の構文を基本的に作成する必要があります。そして distutils や zc.buildout では宣言型と命令型という2つの完全に違う仕組みを使用する必要があります。
次に私を悩ませたのは Python ツールの状態です。私のプロジェクトで使用するツールの設定とコマンドラインで統合インタフェースを持つことは良いことです。私がプロジェクトに取り入れた全てのツールは新たなコマンドラインインタフェースと、さらに設定ファイル(そういった設定ファイルはプロジェクトのメタデータが重複する)を追加します。
Paver はできるだけ(同じファイルにデコレータで関数を追加するだけで)命令型プログラミングに対して宣言型の簡単なエスケープハッチで共通タスクを扱えるように設定します。あなたのプロジェクトに関連する設定オプションはビルドやデプロイ環境を構築する部品から全て同時にアクセスできます。そして全てが Python で記述されるので for ループのやり方を推測しなくて済みます。
もちろん distutils のようなツールで提供された優れたインフラを再構築することには意味がありません。そのため Paver は実際に distutils やその他のツールを直接使用します。
Paver は実際に distutils の拡張の仕組みも提供します。ファイルやディレクトリを操作する、サンプルコードをドキュメントの中で洗練して扱う、隔離された virtualenv 環境へソフトウェアが簡単にインストールされるようにブートストラップスクリプトをビルドするといったような便利な機能セットを追加します。
私は既に SitePen のサポートでプロジェクトのユーザインタフェースで Paver を使用しています。さらに私は Paver そのものを管理するために Paver を使用しています!それは私にとってはとても便利で、プロジェクトで必要とされるどんなスクリプティングでも Paver でとても簡単に行うように設定します。