Personal tools
現在位置: ホーム → Users → tacaco's Home → zc.buildoutを使ってプロジェクトを管理する
 

zc.buildoutを使ってプロジェクトを管理する

eggs、setuptoolsと依存管理、そして開発環境のセットアップにzc.buildoutを使う方法を学びます。

本文書は、Managing projects with zc.buildoutを日本語に翻訳したものです。

はじめに

あるいは、通常の方法でのZopeインスタンスの何が問題なのか？

このチュートリアルはどのようにPlone3を「buildout」を使ってインストールするか、そして、Ploneの機能を拡張するプロダクトを加えるときにbuildoutをどう使用するかを紹介します。buildoutは（ZopeとPloneといくらかのサードパーティプロダクツあるいは必要なライブラリを含む）依存関係とあなたのプロジェクトのための作成したコードの管理ができる環境となります。自分で開発してコードを書く予定がなくても、しっかりとよくテストされた方法であるbuildoutを利用して簡単にPloneをインストールできます。

Plone3.0の前、GUIインストーラーを使わなかった多くの開発者とユーザーは、いくつかのプロダクトをProductsフォルダにドロップすることでZopeインスタンスをセットアップしていました。残念ながらこのアプローチはいくつかの問題を抱えています。

  • 従来の方法でインストールされたZopeインスタンスはPython eggとして配布されるかsetuptools名前空間を持つパッケージを使用することができません。Plone3の多くの新しいパッケージはこの方法で作られていて、今後ますます沢山のサードパーティモジュールもそうなるでしょう。
  • eggが保有するメタデータにアクセスすることなしに、Zopeの外では再利用できないモノシリックなプロダクトを指向すると、開発者たちは彼らの仕事をより再利用出来る複数のパッケージを考慮に入れることがあまりに時間がかかるか混乱させるとわかるかもしれません。
  • いくつかの進んだツールなしに、異なる環境をまたがってセットアップを繰り返すのは面倒です。

今後eggはより重要になってくるので、開発者は自らののコードを管理するのにもっと適切なツールを使うことを検討すべきです。zc.buildoutはこのあと「buildout」としてだけ言及するそういったツールの一つです。このチュートリアルではデプロイメントと同様に日々の開発のためにbuildoutを使う方法を紹介します。

パッケージ、プロダクトとエッグ

さらに詳細な中核のコンセプトを見てみましょう。

専門用語

先に進む前にいくつかの正しい専門用語を理解しましょう。

ソフトウェアホーム($SOFTWARE_HOMEは環境によって変化する)
Zopeインストールの中で、lib/pythonディレクトリはソフトウェアホームとして知られるZopeアプリケーションサーバーの中核を作る全てのPythonコードを含みます。様々なZope 3パッケージはここで配布されます。
Zopeインストール (Zope installation)
ダウンロードとZopeをコンパイルによって、あるいはバイナリのZopeインストーラーの一つを使って得られるもの
Zopeインスタンス
一つのZopeで複数のインスタンスをサポート出来ます。Zopeからmkzopeinstance.pyスクリプトは新しいインスタンスを作るのに使われていました。それぞれのインスタンスは、サーバーをスタートやストップするコントロールスクリプト、コンフィギュレーションファイルのzope.conf、プロダクツディレクトリ、そしてZODBを含むData.fsファイルを持ちます。このチュートリアルでは、buildoutにZopeインスタンスの作成と設計をさせましょう。
インスタンスホーム($INSTANCEHOMEは環境によって変化する)
現在のZopeインスタンスへのパス
Pythonパス($PYTHONPATH環境によって変化する　別名　sys.path)
PythonインタプリタはPythonパスからわかる一つ以上のフォルダの中でモジュールを探すでしょう。Zopeが動いている時、これは通常、標準のライブラリを構成しているグローバルなパイソンモジュール、第三者の「グローバルな」モジュールとeggがインストールされているインタプリタのサイトパッケージディレクトリ、Zopeソフトウェアホーム、およびインスタンスホームの中のlib/pythonディレクトリを含んでいます。このチュートリアルで、私たちはbuildoutがランタイムの時にいくつかの特定のeggをpythonpathにどうやって追加するかをみるでしょう。
Pythonパッケージ
再配布可能なPythonモジュールを記述する一般用語。最も基本的なレベルでは、パッケージは__init__.pyファイルといくつかのPythonコードのあるディレクトリです。
Zopeプロダクト
特別な種類のPythonパッケージは以前はZopeを拡張していました。Zopeの古いバージョンでは、すべてのプロダクツはZopeインスタンスのProductsディレクトリの中にディレクトリがあり、そして"Products"という名前で呼ばれ始めたPythonモジュールをもちます。例えば、PloneのコアはProducts.CMFPloneとしてPythonに知られているCMFPloneと呼ばれるプロダクトです。
Python egg
パッケージ方法とPythonパッケージを配布します。Eggは依存関係についての情報同様に、著者名と電子メールアドレス、ライセンス情報などのメタデータとsetup.pyファイルを含んでいます。setuptoolsは、eggの仕組みの動力であるPythonライブラリで、インストールするeggのために依存関係を自動的に見つけダウンロードしてくる事が可能です。これは二つの異なるeggに同じ依存関係の異なるバージョンを同時に使用することを可能にします。eggはまた、一般的なプラグイン機能の一つであるエントリーポイントと呼ばれる機能をサポートします。私たちはここで詳細に拡張ポイントをカバーしませんが、あなたは(eggの他の特徴と)それらについてPEAKウェブサイトでもっと読む事が出来ます。
The Cheese Shop (aka PyPI, the Python Package Index)
The Cheese ShopはPythonパッケージの数千のホストのインデックスです。あなたが特定のパッケージを探す時に閲覧出来ます。より重要なのは、setuptools(そしてbuildout及びeasy_installスクリプト)は、自動的にeggをダウンロードして、インストールするためにこのインデックスに照会できます。
easy_install
Cheese Shopを検索し、グローバルなPython環境にパッケージをインストールするのに使用出来るコンソールスクリプト。私たちは、グローバルバーションの曖昧さを避け、ローカルのそれぞれのbuildoutプロジェクトのeggをbuildoutで管理するようになってからは、これをいくつかのグローバルパッケージのインストールに使うだけでしょう。
Namespace package
setuptoolsの特徴は一つのトップレベル名前空間を共有する別々のパッケージを多数配布することを可能にします。例えば、plone.themaとplone.portletsパッケージはともにトップレベルの「Plone」名前空間で共有しますが、それらは別々のeggとして配布されます。インストールした時、それぞれのeggは自分自身のディレクトリ（あるいはそのディレクトリの圧縮されたアーカイブかも知れない）に存在する。名前空間パッケージがなければ、私たちは例えば、plone/themeとplone/portletsのような全ての子パッケージを含んだトップレベルのPloneディレクトリで、1個の巨大なPloneパッケージを配布しなければならなかったでしょう。

魔法のProducts namespace

Zopeがある「プロダクト」を見つけた時、それはZMIのルートにあるControl_Panel/Productsにエントリを作り、そしてinitialize()メソッドを実行し、Zopeを起動するたびにプロダクツのルートの__init__.pyファイルを見つけます。どのパッケージもPloneコンテキストの中で使われるパッケージになる必要はないが、プロダクトらしいものになることが求められます。

  • GenericSetupプロファイル
  • スキンディレクトリは（Zope3スタイルのbrowser viewsでなく）portal_skinsツールにレイヤーとしてインストールされます

プロダクトを作る最も簡単な方法はProducts以下にegg-readyパッケージを作るのにPaster/ZopeSkelを使うことです。名前空間はbasic_namespaceテンプレートを使用します。

  $ paster create -t basic_namespace Products.myproduct
  Selected and implied templates:
    ZopeSkel#basic_namespace  A project with a namespace package

  Variables:
    egg:      Products.myproduct
    package:  productsmyproduct
    project:  Products.myproduct
  Enter namespace_package (Namespace package (like plone)) ['plone']: Products
  Enter package (The package contained namespace package (like example)) ['example']: myproduct
  ... accept defaults to end

もしあなたがbuildoutを使用しているなら、srcディレクトリにあなたのパッケージを作成して、buildout.cfgの[develop]と[instance/eggs]セクションにその参照を追加します。

  develop =
      src/Products.myproduct
  ...
  [instance]
  ...
  eggs =
      ${buildout:eggs}
      ${plone:eggs}
      Products.myproduct

bin/buildoutを実行し、srcディレクトリにあるあなたのegg-readyプロダクトの開発をセットアップをします。完成した時に配布eggにします。Zope2プロダクトとしてnamespace/directoryプロダクツの外でパッケージ(eggで配布されたそれを含む)を使用することが可能です。フラットな名前空間に全てを単一に保つのが不自然であると感じて、多くの開発者たちはこのアプローチを好みます。

追加の手順がこれに必要です。Zope 2.10.4より前、これはプロダクト名前空間のプロダクトに必要です。

私たちはパッケージのconfigure.zcmlに以下のように追加しなければなりません。

<configure 
    xmlns="http://namespaces.zope.org/zope"
    xmlns:five="http://namespaces.zope.org/five">

    <five:registerPackage package="." initialize=".initialize" />

</configure>

次に、それはプロダクト名前空間の外のパッケージはZope起動時に自動的に検出されないことを理解することは重要です。もしそれらが(大半のパッケージのように)configure.zcmlファイルに含まれているなら、それをどこからか明示的に含まなければいけません。
これは以下の通りです。

  • 他のパッケージのconfigure.zcmlファイル
  • Zopeのsite.zcml、全てのZCMLファイルのルート、インスタンスホームの中のetcディレクトリの中で見つかる場所
  • ZCMLのスラグは、zopeインスタンスのetc/package-includesディレクトリの中にmy.package-configure.zcmlのような名前で1行で作られます。

全てのケースでシンタックスは同じです。

<include package="my.package" file="configure.zcml" />

もし、meta.zcmlまたはoverrides.zcmlファイルがあるなら、これらのための指示を加えることが出来ます。スラグを使用しているなら、それに従って、例えばmy.package-meta.zcmlまたはmy.package-overrides.zcmlと命名しなければなりません。スラグは1つ以上の行を含むことができません。

このチュートリアルの後の方で、どうやってbuildoutは私たちのために自動的にslugの管理を出来るのかを見ます。

前提条件

私たちが開始する前にあなたに必要ないくつかのこと

私たちがZopeとPlone管理のbuildoutを作る前に、いくつかの気をつける前提条件があります。
最初に、もしあなたが既に持っていなければ、あなたは妥当なPythonインタープリターが必要でしょう。

  • あなたのプラットフォームにPython2.4をインストールし、システムのPATHにそれを追加します。コマンドラインでpython -vをタイプした時にPython2.4と出れば一番簡単です。
  • もしあなたがRPMのようなOSのパッケージを使ってPythonをインストールしていたなら、あなたはpython-develのような開発パッケージを必ず手に入れてください。このPythonヘッダファイルに含まれるものは私たちが後でZopeをコンパイルするのに使います。もしあなたがソースから、あるいはPython Windowsインストーラーを使ってインストールしていたら、あなたはそれを既にこれらを持っているでしょう。
  • Pythonインタープリタの中にPython Imaging Library、PILのインストール

そしてez_setup.pyをダウンロードし下記のように実行します。

  $ python ez_setup.py

これはsetuptoolsとeasy_installスクリプトをダウンロードしインストールします。コンソールの出力を見るとeasy_installがどこにインストールされたかがわかります。もしこれがあなたのシステムPATHになければ、パスにこのディレクトリを追加するべきです。
最後にeasy_installを使ってZopeとPloneの開発のためのスケルトンのテンプレート集のZopeSkelをインストールします。

  $ easy_install -U ZopeSkel

これはPasteスクリプトと様々なその他の依存関係を作ります。もしあなたがシステムのパスにPythonコンソールスクリプトディレクトリ(easy_installの場所)を追加したなら、あなたはpasterコマンドを実行できるでしょう。
あなたは以下でそれをテスト出来ます。

  $ paster create --list-templates
  Available templates:
    basic_namespace:          A project with a namespace package
    basic_package:            A basic setuptools-enabled package
    basic_zope:               A Zope project
    nested_namespace:         A project with two nested namespaces.
    plone:                    A Plone project
    plone2.5_theme:           A Theme for Plone 2.5
    plone2_theme:             A Theme for Plone 2.1 & Plone 2.5
    plone3_buildout:          A buildout for Plone 3 projects
    plone3_theme:             A Theme for Plone 3.0
    plone_app:                A Plone App project

あなたの出力は少し異なっているかもしれません、しかし少なくともplone3_buildoutとploneテンプレートがあるはずです。

Windowsのための追加インストールステップ

もしあなたがWindowsを使っているなら、そこにはあなたがやる必要のあるいくつかのことがあります。

最初に、Python2.4のためにPython Win32 エクステンションをインストールします。

もしあなたがバイナリーのインストーラーを使うよりあなた自身でZopeをコンパイルするつもり、あるいはあなたがC拡張でeggをコンパイルする必要があるなら、mingw32コンパイラを必要とします。 インストーラーが尋ねた時最小限のbaseとmakeモジュールの選択を確実にしてください。デフォルトではこれはC:\MingW32にインストールされます。インストールディレクトリの内側に、例えばC:\MingW32\binのようなbinディレクトリがあるでしょう。あなたのシステムPATHにこれを追加します。

最後に、あなたはmingw32コンパイラを使ってPythonのdistutilsパッケージをコンフィギュアする必要があります。(デフォルトのC:\Python24にpythonがインストールされていると仮定して)C:\Python24\Lib\distutilsディレクトリの中にdistutils.cfgというファイルを作成します。これをノートパッドで編集して、以下を追加します。

  [build]
  compiler=mingw32

プロジェクトのためにbuildoutを作成する

依存関係のとおりにploneとその他のサードパーティプロダクトを追加して、プロジェクトのために新しいbuildoutを作成する方法

新しいbuildoutを作成する準備をします。buildoutはプロジェクトを作る全てのパーツ、Zopeインスタンス、Ploneソース、カスタムコンフィギュレーションオプションとあなたのプロジェクトのソースコードを含むディレクトリです。
このようにして作ります。

  $ paster create -t plone3_buildout myproject

これは一連の質問を尋ねてきます。もしあなたがbuildoutがダウンロードしてコンパイルする方より既存のインストールされているZopeを使いたいならzope2_installに絶対パスを指定します。
同様に、もしあなたがbuildoutにコアのPloneプロダクツのダウンロードして欲しくないなら、あなたは全てのプロダクツを含む既存のディレクトリを指定出来ます(Plone3のeggをダウンロードするでしょうが、後で見るように、それは複数のbuildout間でeggのディレクトリを共有可能です)。あなたはZopeアドミニストレータのユーザー名とパスワードを入力する必要があるかもしれません。そして、開発の間verboseセキュリティとデバッグモードをつけたがっているかもしれません。

新しい自分のプロジェクトディレクトリを作成し、buildout bootstrapスクリプトを実行します。

  $ cd myproject
  $ python bootstrap.py

これはディレクトリとスクリプトを幾つか作成し、zc.buildout eggの最新バージョンをダウンロードします。このステップは一度しか必要としないでしょう。
すぐ開始するには以下のコマンドを実行します。

  $ ./bin/buildout

これはジェネレートされたbuildout.cfgファイルを読み、様々なパーツを実行し、Zopeをセットアップし、Zopeインスタンスを作成し、Ploneをダウンロードしインストールします。私たちはまもなくさらに詳細にこのファイルについて説明します。

あなたはbuildout.cfgを変更する度に./bin/buildoutコマンドを実行する必要があります。もしあなたがbuildoutにオンラインでeggのアップデートバージョンを探したりその他のアーカイブをダウンロードしたりしたくないなら、あなたはbuildoutをオフラインモードとしてアップデートせずに実行すること事が出来ます。

  $ ./bin/buildout -No

Zopeを起動します。

  $ ./bin/instance fg

インスタンススクリプトは標準のZopeインスタンスで見つけられるzopectlに類似しています。あなたは、./bin/instanceを使ってZopeをデーモンモードで起動することができます。またテストを実行するのに下記を使えます。

  $ ./bin/instance test -s plone.portlets

buildoutディレクトリ

私たちはbuildout.cfgの中に入る前に、buildoutが私たちの為に作るディレクトリを少し見てみましょう。

bin/
様々な実行できるbuildoutコマンドとZopeコントロールスクリプトのインスタンスを含んでいます。
eggs/
buildoutによってダウンロードされたeggを含みます。これらはbinディレクトリのコントロールスクリプトによって明示的に起動させられます。
downloads/
Zopeのソースコードアーカイブのようなeggでないダウンロードを含んでいます。
var/
ログファイル(var/logの中)とファイルストレージのZODBデータ(var/filestorage/Data.fsの中)を含んでいます。Buildoutはこれらを決して上書きしないでしょう。
src/
最初は空です。あなたはあなた自身の開発するeggとbuildout.cfgの中でそれらを参照する場所に出来ます。詳細は後ほど。
products/
これはZopeインスタンスのProductsディレクトリ(大文字で始まっている違いに注意)に似ています。もしあなたがいくつかの古いZope2形式のプロダクトを開発するなら、この場所で行います。私たちはbuildoutが自動的にダウンロードしプロダクツのアーカイブを管理する方法を見るでしょう。しかし、もしあなたがプロダクトの依存関係を手動で得たいあるいはSubversionからチェックするなら、この場所で行います。
parts/
buildoutによって管理されるデータとコードを含みます。私たちの場合、それはローカルのインストールされたZope、buildoutに管理されたZopeインスタンスとPloneのソースコードを含んでいます。一般的には、buiodoutがあなたの変更を上書きしてしまうかもしれないので、あなたはこのディレクトリは何も修正しないほうがよいでしょう。

あなたは開発者間で共有しているソースコードリポジトリをbuildoutディレクトリの中でチェック出来ます。この場合、bin/,eggs/,downloads/,var/とparts/ディレクトリを無視した方がいいでしょう。各開発者はこれを戻すのにbootstrap.pyを実行出来、そして通常とにかくローカルのコピーが必要となるでしょう。全てのコンフィグレーションはbuildout.cfgファイルの中にあり、そして全てのカスタムコードはsrcあるいはproductsディレクトリのなかにあったほうがいいでしょう。

buildout.cfgを理解する

メインの buildout コンフィグレーションファイルの管理方法

buildout.cfgは新しいbuildout環境のなかのもっとも重要なファイルです。
これはそれがどう見えるかです。

  [buildout]
  parts =
      plone
      zope2
      productdistros
      instance
      zopepy

  # Add additional egg download sources here. dist.plone.org contains archives
  # of Plone packages.
  # ここで追加のeggのダウンロードソースを加えます。dist.plone.orgは
  # Ploneパッケージのアーカイブを含みます
  find-links =
      http://dist.plone.org
      http://download.zope.org/ppix/
      http://download.zope.org/distribution/
      http://effbot.org/downloads
 
  # Add additional eggs here
  # elementtree is required by Plone
  # ここで追加のeggを加えます。elementtreeはPloneに必要とされています。
  eggs =
      elementtree
    
  # Reference any eggs you are developing here, one per line
  # e.g.: develop = src/my.package
  # あなたがここで開発するあらゆるeggの参照で、1行に一つです。
  # 例えば：develop = src/my.package
  develop =

  [plone]
  recipe = plone.recipe.plone

  [zope2]
  recipe = plone.recipe.zope2install
  url = ${plone:zope2-url}

  # Use this section to download additional old-style products.
  # List any number of URLs for product tarballs under URLs (separate

  # with whitespace, or break over several lines, with subsequent lines
  # indented). If any archives contain several products inside a top-level
  # directory, list the archive file name (i.e. the last part of the URL, 
  # normally with a .tar.gz suffix or similar) under 'nested-packages'.
  # If any archives extract to a product directory with a version suffix, list
  # the archive name under 'version-suffix-packages'.
  # このセクションを使って追加の古いスタイルのプロダクトをダウンロードします。
  # urlsの下にプロダクトtarballの為の全てのURLを記載してください(空白で分離
  # するか、字下げされた次の行とでいくつかの行に改行する)。
  # いくつかのアーカイブがトップレベルディレクトリの中にいくつかのプロダクトを
  # 含むなら、nested-packagesの下にアーカイブファイル名(すなわち、URLの最後の
  # 部分、通常、tar.gz接尾語あるいは類似のものと)を記載します。
  # バージョン接尾語でプロダクトディレクトリにどれかのアーカイブを抽出するなら、
  # 'version-suffix-packages'下にアーカイブ名を記載します。
  [productdistros]
  recipe = plone.recipe.distros
  urls =
  nested-packages =
  version-suffix-packages = 

  [instance]
  recipe = plone.recipe.zope2instance
  zope2-location = ${zope2:location}
  user = admin:admin
  http-address = 8080
  debug-mode = on
  verbose-security = on

  # If you want Zope to know about any additional eggs, list them here.
  # This should include any development eggs you listed in develop-eggs above,
  # e.g. eggs = ${buildout:eggs} ${plone:eggs} my.package
  # Zopeに追加のあらゆるeggについて知らせたい時、ここにそれらを記載します。
  # これは上のdevelop-eggsに記載した開発中のeggを含んだ方がいいでしょう。
  # 例： eggs = ${buildout:eggs} ${plone:eggs} my.package
  eggs =
      ${buildout:eggs}
      ${plone:eggs}

  # If you want to register ZCML slugs for any packages, list them here.
  # e.g. zcml = my.package my.other.package
  # もしあなたがいくつかのパッケージの為にZCMLスラグを登録したいなら、ここにそれらを記載します。
  # 例： zcml = my.package my.other.package
  zcml = 

  products =
      ${buildout:directory}/products
      ${productdistros:location}
      ${plone:products}

  [zopepy]
  recipe = zc.recipe.egg
  eggs = ${instance:eggs}
  interpreter = zopepy
  extra-paths = ${zope2:location}/lib/python
  scripts = zopepy

一つずつこのファイルを通しで見てみましょう。

メインのbuildoutセクション

[buildout]セクションはファイルの出発点です。
このファイルの後の別々のセクションに設計される多くの"parts"を記載します。各パートには、例えば、Zopeをビルドする、あるいはZopeインスタンスを作成するなどの特定のタスクを実行する方法を知っているeggの名前の提携のrecipeを持ちます。通常recipeはいくつかのコンフィグレーションオプションを持っています。
グローバルセッティングは次のようになっています。

  [buildout]
  parts =
      plone
      zope2
      productdistros
      instance
      zopepy

  find-links =
      http://dist.plone.org
      http://download.zope.org/ppix/
      http://download.zope.org/distribution/
      http://effbot.org/downloads

  eggs =
      elementtree
    
  develop =

これは、partsのplone、zope2、productdistros、instance、およびzopepyがその順番で実行されると指定しています。そして、ダウンロードのためにeggを探している時、それがいくつかのURLの1つを探せるとbuildoutに示します。さらに、それはつねにCheese Shopを探すでしょう。

次に、私たちはbuildoutがダウンロードしてインストールした方がいいあらゆるeggを記載出来ます。これはバージョン指定を含むかもしれません。例えば、あなたがSQLAlchemy0.3が欲しくて0.4ではない場合、次のように記載出来ます。

  eggs = 
      elementtree
      sqlalchemy>=0.3,<0.4dev

最後に、私たちはeggがソース形式で抽出されるディレクトリを指定する事によって開発eggを記載出来ます。
例えば

  eggs =
      elementtree
      my.package

  develop = 
      src/my.package

これはmy.packageと呼ばれるeggがsrcディレクトリ以下にあることを前提とします。私たちはこのチュートリアルの少し後で、このようなeggを作る方法を学ぶでしょう。開発eggはZopeのためにインストールされたeggのワーキングセットに自動的に追加されないため、実際のeggの依存関係についてmy.packageを記載しなければならない点に注意して下さい。

[plone]セクション

これはとても簡単です。これはPloneのプロダクツとeggをダウンロードするのにplone.recipe.ploneを使うだけです。

  [plone]
  recipe = plone.recipe.plone

これは有効な最新リリースを使用するでしょう。plone.recipe.ploneの為のバージョン番号はPloneそれ自身のためのバージョン番号に一致します。
したがって、確実に3.1でなくいつも3.0.xリリースを得るにはこうします。

  [plone]
  recipe = plone.recipe.plone>=3.0,<3.1dev

recipeが実行される時、Ploneのプロダクトはparts/ploneにインストールされるでしょう。eggは後の[instance]セクションで参照されるbuildoutの変数${plone:eggs}を通して有効にされ、そしてZope推奨バージョンのURLは変数${plone:zope2-url}で有効です。

[zope2]セクション

このパートではplone.recipe.zope2installを使ってZope2をビルドします。もし、あなたが既にインストールされているZopeを指定するなら、この部分は必要ありません。そうでなければ、このようになります。

  [zope2]
  recipe = plone.recipe.zope2install
  url = ${plone:zope2-url}

ここで、[plone]部分によって外に送られているようにZopeのためのダウンロード位置を参照します。これは私たちがいつもZopeの推奨バージョンを得る事を確実にします。Zopeの異なるバージョンを使用したいなら、代わりに手動でダウンロードURLを指定出来ます。

recipeが実行されると、Zope2はparts/zope2にインストールされます。Zopeソフトウェアホームはparts/zope2/lib/pythonになります。

[productdistros]セクション

これはZope2スタイルの配布(アーカイブ)のダウンロードを可能にし、それらをZopeで利用可能にするrecipe、plone.recipe.distros を使います。
これは初め空です。

  [productdistros]
  recipe = plone.recipe.distros
  urls =
  nested-packages =
  version-suffix-packages =

しかし、いろいろなダウンロードを記載出来ます。
recipeは　実際のプロダクトディレクトリ(入れ子にされたペッケージ)のバンドルを含む一つのトップレベルディレクトリを含むアーカイブ、あるいはディレクトリ名のバージョン番号を持ち、実際のプロダクトディレクトリ(バージョン接尾語パッケージ)を手に入れるためにリネームされる必要があるパッケージに対処出来ます。

例えば、これはCacheFu1.1をダウンロードする方法です。

  [productdistros]
  recipe = plone.recipe.distros
  urls =
      http://plone.org/products/cachefu/releases/1.1/CacheFu-1.1.tgz
  nested-packages =
      CacheFu-1.1.tgz
  version-suffix-packages =

あなたは行を分ける事で多数のダウンロードを指定出来ます。recipeが実行される時、ダウンロードしたプロダクトのためのプロダクトディレクトリはparts/productdistrosに見つかります。

[instance]セクション

インスタンスセクションはそれを全部一緒に引きます。それはplone.recipe.zope2instanceスクリプトを使ってZopeインスタンスを設計します。これはそれがどう見えるかです。

  [instance]
  recipe = plone.recipe.zope2instance
  zope2-location = ${zope2:location}
  user = admin:admin
  http-address = 8080
  debug-mode = on
  verbose-security = on
  eggs =
      ${buildout:eggs}
      ${plone:eggs}
  zcml = 
  products =
      ${buildout:directory}/products
      ${productdistros:location}
      ${plone:products}

ここで[zope2]部分からZope2インストールを参照します。もしあなたがbuildoutを作成した時に自分で場所を指定したなら、あなたはここでそれを見るでしょう。そして、私たちは初期のアドミンユーザーとパスワード、そしてZopeが向かっているポートを特定します。私たちはデバッグモードとverbose securityもonにします。これらのオプションはこのインスタンスに適したzope.confファイルを生成するのに使われます。使用出来るオプションの詳細はCheese Shopのrecipeページを参照のこと。

次に、どのeggがZopeに利用出来るようにするかを指定します。これはPloneによって明示されたeggだけでなく[buildout]セクションからのグローバルeggを参照します。ファイルの先頭でこれらを指定するのが一般的に簡単ですが、${buildout:eggs}ワーキングセットのなかに含まれているように、ここに追加のeggを加える事が出来ます。

前に説明したように、Zope3のconfigure.zcmlファイルはeggのために自動でロードしないかプロダクトの名前空間でないパッケージです。通常のパッケージのためにZCMLファイルをロードするには、zcmlオプションの下にパッケージを記載することによってZCMLスラッグを作るbuildoutを作る事が出来ます。

  zcml =
      my.package
      my.package-overrides

これはmy.packageがbuildoutの中で以前参照されたと仮定します。これはこのパッケージからメインのconfigure.zcmlとoverrides.zcmlの二つを読み込みます。

最後に、私たちは伝統的なインスタンスの中のProductsディレクトリと同種の、Zope2スタイルプロダクツを含むあらゆるディレクトリを記載します。メインのbuildoutディレクトリのproducts/ディレクトリがどのように最初に来て、［productdistros］部分でダウンロードされるプロダクツが続き、［plone］部分によってダウンロードされたプロダクツが続くようになるかについて注意してください。これはPloneがプロダクトとして出荷しても、トップレベルのproductsディレクトリに同じ名前でプロダクツを置く事によって、(例えばより新しいプロダクトで)それを上書きすることが出来ることを意味します。

recipeが実行される時、Zopeインスタンスホームはparts/instanceにあり、そしてコントロールスクリプトは./bin/instanceに作成されています。

[zopepy]セクション

この最後のセクションは全てのeggとZopeが起動中に持つパッケージのPythonインタープリタを作成します。これはテスト用途にとても有効です。

  [zopepy]
  recipe = zc.recipe.egg
  eggs = ${instance:eggs}
  interpreter = zopepy
  extra-paths = ${zope2:location}/lib/python
  scripts = zopepy

ここで私たちはeggを[instance]セクションからコピーし、そしてZopeインスタンスホームのpythonパスにインクルードします。
recipeが実行される時、スクリプトは./bin/zopepyに作られるでしょう。

buildoutデフォルトファイルの作成

これは複数のbuildoutをまたがって設定を共有することを可能にし、時間とディスクスペースを節約することとを可能にします。

すべてのbuildoutに影響を与える「グローバル」オプションをセットするには.buildoutディレクトリ(先頭のドットに注意)をあなたのホームディレクトリに作成し、default.cfgというファイルを追加します。ここでセットしたいくつかのオプションはbuildout.cfgファイルそれ自体に特別に記載したいくつかのオプションによって上書きされない限り、あなたが実行したいくつかのbuildout.cfgの一致したセクションに適用されるでしょう。
一般的なオプションは

executable
システムのデフォルトより他のpythonインタープリタを指定する。これは、もしあなたがPython2.5をインストールしているが、Python2.4の他のインストールを使うのにあなたのbuildoutを使いたいなら有効です。
eggs-directory
eggがダウンロードされるディレクトリを指定します。これは複数のbuildoutで同じeggを共有することを許可し、ディスクスペースとダウンロード時間を節約します。特定のbuildoutによって明示的に要求されるそれらのeggだけが起動することに注意します。eggディレクトリはいつも使用されるよりもっと沢山のegg(あるいは同パッケージの沢山の異なったバージョン)を含んでいるかもしれません。
download-directory
ダウンロードアーカイブのための共有ディレクトリを指定します。これもまたディスクスペースとダウンロード時間を節約出来ます。

これは3つ全てを設定した~/.buildout/default.cfgの例です。

  [buildout]
  executable = /opt/python24/bin/python
  eggs-directory = /home/username/.buildout/eggs
  download-cache = /home/username/.buildout/downloads

これはPthon2.4が/opt/python2.4にインストールされていると仮定しています。最後の2つのオプションが動くために、あなたは~/.buildoutディレクトリの中にeggsディレクトリとダウンロードディレクトリを作る必要があります。

サードパーティプロダクトのインストール

これらのツールを使って新しいパッケージをインストールする方法

新しいサードパーティプロダクツのインストール方法はそれがeggのパッケージなのか伝統的なZope2プロダクトなのかどうかに依存します。

伝統的なZope2プロダクトのインストール

伝統的なZope2プロダクトを試す最も簡単な方法はbuildoutの内側でproductsフォルダの中にそれを抽出することです。もしZopeインスタンスの中のProductsフォルダにドキュメント参照があれば、これは同じことです。

しかし、このアプローチはあなたのプロジェクトを再配布し、他の開発者と共有することを難しくします。buildoutをダウンロードし、あなたのためにパッケージをインストールさせることがしばしば予測されます。あなたはbuildout.cfgの[productdistros]セクションでこう出来ます。例えば、これはあなたのプロジェクトのためにDocFinderTabとCacheFuをどうやってインストールできるかです。

  [productdistros]
  recipe = plone.recipe.distros
  urls =
      http://www.zope.org/Members/shh/DocFinderTab/1.0.2/DocFinderTab-1.0.2.tar.gz
      http://plone.org/products/cachefu/releases/1.1/CacheFu-1.1.tgz
  nested-packages =
      CacheFu-1.1.tgz
  version-suffix-packages =

私たちが入れ子にされたパッケージの下でそれを記載するように、CacheFuがサブディレクトリに多くのプロダクツを含む単一ディレクトリとして配布されていることに注意してください。
いつものように、buildout.cfgを変更したら、buildoutを再度実行しなければなりません。

  $ ./bin/buildout

eggのインストール

eggがCheese Shopあるいはどこか他でリリースする限り、buildoutは明示的に指定された依存関係を含んでそれをダウンロードしてインストール出来ます。単にeggのオプションでは、eggと任意のバージョン（そうでなければ利用可能な最新のもの）を記載します。

  [buildout]
  ...
  eggs = 
      elementtree
      borg.project>=1.0b1,<2.0dev

もしあなたがbuildoutにCheese Shopのもの以外のインデックスを検索して欲しいなら、eggのためにダウンロード先を含むリンクのURLを追加することが出来ます。実際、私たちは既に、elementtreeはCheese Shopディレクトリでなく、http://effbot.org/downloadsで見つかるこの例で見ています。要するに

  [buildout]
  ...

  find-links =
      http://dist.plone.org
      http://download.zope.org/ppix/
      http://download.zope.org/distribution/
      http://effbot.org/downloads

  eggs =
      elementtree

私たちはZopeとPlone eggのためのダウンロード場所の幾つかも記載しています。
もう一度、変更の効果が現れるようにbuildoutを再実行します。

  $ ./bin/buildout

開発egg

もし、あなたのegg用のリリースでない、あるいはSubversionの中でeggのトラッキングをしたいならsrcディレクトリ以下をチェックしてください。トップレベルのsetup.pyファイルを含む全てのeggを得ることを確実にします。例えば、plone.portletsの開発trunkを得るために、eggが実行します。

  $ cd src
  $ svn co https://svn.plone.org/svn/plone/plone.portlets/trunk plone.portlets

そして、buildout.cfgに次のように追加します。

  [buildout]
  ...
  eggs =
      ...
      plone.portlets

  develop =
      src/plone.portlets

注意

  • 開発オプションはインストールされたeggソースの相対パスを含みます。buildoutは適したsetup.pyをこのディレクトリの中に見つけることを予想しています。
  • egg開発はいつも通常のeggより優先されます。
  • あなたはまだそれがインストールされるためにeggの名前をeggオプションに記載する必要があります。
  • もしあなたがPloneに含まれるeggを上書きしているなら、あなたは代わりにそれを[Plone]部分のeggセクションに記載する必要があるかもしれません。
  [buildout]
  ...
  develop =
      src/plone.portlets
  ...

  [plone]
  recipe = plone.recipe.plone
  eggs = 
      plone.portlets

これはなぜならplone.recipe.ploneは様々なeggのどのバージョンを使用したらよいかに関して非常に明白で、リリースされたPloneと同様に稼働し続けるのを確実にします。

(plone.recipe.ploneのような)buildout recipeはeggとして配布されてます。あなたは開発オプションの下にあるその記載によってrecipeの開発eggを使用出来ます。関係のある部分のrecipeオプションによって参照される以後、eggオプションの下に明示的に記載される必要がありません。

ZCMLファイル管理

ZopeはProducts.* 名前空間の中でないパッケージのために自動的にconfigure.zcmlファイルをロードしないことを理解することは重要です。代わりに、あなたは明示的にパッケージに参照をつけなければなりません。buildoutは[instance]部分の下にzcmlオプション(とZCMLスラグとして知られる)参照を作る事が出来ます。これはborg.projectがZopeで利用可能にする確実な方法です。

  [buildout]
  ...
  eggs =
      elementtree
      borg.project
  ...

  [instance]
  ...
  zcml = 
      borg.project

overrides.zcmlかmeta.zcmlを読み込む必要があるなら、あなたは以下のように構文を使用出来ます。

  zcml =
      some.package
      some.package-overrides
      some.package-meta

ポリシープロダクト

多くの開発者たちは様々な依存関係を調整する単一のポリシープロダクト(また、デプロイメントプロダクトとして知られています)を作る事を好みます。
もしあなたがそのようなプロダクトを持っているなら、ポリシープロダクトのconfigure.zcmlファイルから様々な依存関係のディレクトリを含みたいかもしれません。このように記載します。

<configure xmlns="http://namespace.zope.org/zope">

    <include package="borg.project" />

</configure>

このケースでは、あなたはまだポリシープロダクトのために(上のzcmlオプションを使用する)一つのスラグを必要とするかもしれません。

新しいパッケージを作る

あなたのbuildoutに新しいeggベースパッケージを加える方法

新しいカスタムパッケージを追加することはサードパーティのそれをインストールするのとそんなに違いはありません。

伝統的なZope2プロダクトを作る

伝統的なZope2プロダクトの作成はトップレベルのproductsディレクトリにそれを置きZopeを再起動します。他に必要なことはありません。
前に説明したように、プロダクトのこの場所は起動時に自動的に見つけられ、そしてconfigure.zcmlファイルは自動的に実行されます。

eggを作る

もちろん、あなたがプロダクトを使用しているならば、あなたはCheese Shopと入れ子にされた名前空間により配布される自動依存管理を含むeggの付加的な特徴から利益を得ることができません。

新しいeggを作るもっとも簡単な方法は既にbuildoutを作るのに使ったpasterコマンドを使用する事です。トップレベルの名前空間(例えばあなたの会社)と固有の名前で新しい基本パッケージを作成しにsrcディレクトリに行き実行します。

  $ cd src
  $ paster create -t plone myorg.mypackage

質問の一連を尋ねられるでしょう。名前空間パッケージとパッケージ名がeggの名前に一致することを確実にしてください。この場合、名前空間パッケージはmyorgでパッケージ名はmypackageです。一般にあなたのパッケージがzip safeかどうかという問いにFalseと答えます。要求された通り、他のメタデータを入力して下さい。

あなたには現在以下があるでしょう。

  • あなたが入力したメタデータを含んだsetup.py
  • myorg.mypackage/myorg/mypackageの中のパッケージ。あなたのソースコードはここにあります。
  • configure.zcmlのスケルトン、tests.py及びいくつかの役に立つ出発点
  • myorg.mypackage/docsの中のいくつかの一般的な文書

もちろんあなたはbuildoutにこのパッケージも追加する必要があります。
buildout.cfgにあなたは以下を持っているかもしれません。

  [buildout]
  ...
  eggs =
      ...
      myorg.mypackage

  develop =
      src/myorg.mypackage

他のパッケージからこのパッケージを含む計画でない限り、あなたは多分ZCMLスラグを必要とします。

  [instance]
  ...
  zcml =
      myorg.mypackage

変更した後にbuildoutを再度実行するのを忘れないように。

  $ ./bin/buildout

依存関係の指定

もしあなたの新しいパッケージが明快な依存関係を持つなら、setup.pyにそれを記載出来ます。このようにして、buildoutは同様にそれらをダウンロードしてインストールできるようになります。依存関係はsetup()メソッドのインストール要求項の中に記載されていて、デフォルトでsetuptoolsは名前空間パッケージをサポートするのに必要なのでここに記載されています。sqlalchemy0.3(しかし、0.4でなく)とMySQL-Pythonドライバーを追加するにはあなたは以下のように修正出来ます。

  install_requires=[
            'setuptools',
            'sqlalchemy>=0.3,<0.4dev',
            'MySQL-Python',
        ],

あなたのeggをCheese Shopにアップロードする

もしあなたがあなたのパッケージをその他のPythonコミュニティと共有して、buildoutとeasy_installのようなツールを使って簡単にインストールしたいならあなたはパッケージをCheese Shopにアップロード出来ます。
そうするまえにあなたがやるべき事

  • 適用できるならば、あなたの最新の変化をコミットして、Subversionでリリースにタグを付けてください。
  • setup.cfgファイルを(一時)取り外してください: これはあなたのパッケージを開発リリースにします。
  • setup.pyの中のバージョン番号を確実に正しくなるようにします。バージョン1.0の第2ベータのための"1.0b2"あるいはバージョン2.1.3の最初のリリースキャンディデートのための"2.1.3rc1"のような一般的な慣習を使います。
  • もしあなたがMac OS X を使っているなら最初にシェル上でexport COPY_EXTENDED_ATTRIBUTES_DISABLE=trueを実行します。さもなければeggはMac OS Xのリソースフォークを含んでしまい、あなたのeggをWindows上で使う時に問題の原因となるでしょう。

準備が出来たら、あなたのパッケージのディレクトリ(例えばsrc/myorg.mypackage)から次のコマンドを実行します。

  $ python setup.py egg_info -RDb "" sdist bdist_egg register upload

もしあなたがまだCheese Shopアカウントを持っていなければ、作成するか尋ねられます。あなたは新しいバージョン(おそらく新しいバージョン番号で)をリリースしたい度にこのコマンドを実行出来ます。

デプロイメントコンフィグレーション

デプロイメントコンフィグレーションのためにbuildoutを使う方法

最後に、よりデプロイメントに適している、もっと高度な設定を見てみましょう。メインのbuildout.cfgファイルに次いで、buildoutのルートにこのファイルをdeployment.cfgとして保存して下さい。

  [buildout]
  extends =
      buildout.cfg

  parts =
      plone
      zope2
      productdistros
      deploymentproducts
      zeoserver
      primary
      secondary
      varnish-build
      varnish-instance

  [deploymentproducts]
  recipe = plone.recipe.distros
  urls =
      http://plone.org/products/cachefu/releases/1.1/CacheFu-1.1.tgz
  nested-packages =
      CacheFu-1.1.tgz
  version-suffix-packages = 

  [zeoserver]
  recipe = plone.recipe.zope2zeoserver
  zope2-location = ${zope2:location}
  zeo-address = 8100

  [primary]
  recipe = plone.recipe.zope2instance
  zope2-location = ${zope2:location}
  zeo-client = true
  zeo-address = 8100
  zodb-cache-size = 5000
  zeo-client-cache-size = 300MB
  user = admin:admin
  http-address = 8080
  debug-mode = off
  verbose-security = off
  eggs =
      ${plone:eggs}
      ${buildout:eggs}
  zcml = 
    
  products =
      ${buildout:directory}/products
      ${productdistros:location}
      ${deploymentproducts:location}
      ${plone:products}

  [secondary]
  recipe = plone.recipe.zope2instance
  zope2-location = ${zope2:location}
  zeo-client = true
  zeo-address = 8100
  zodb-cache-size = 5000
  zeo-client-cache-size = 300MB
  user = ${primary:user}
  http-address = 8081
  debug-mode = on
  verbose-security = on
  eggs = ${primary:eggs}
  zcml = ${primary:zcml}
  products = ${primary:products}
  zope-conf-additional =
      zserver-threads 1
    
  [varnish-build]
  recipe = plone.recipe.varnish:build
  url = http://puzzle.dl.sourceforge.net/sourceforge/varnish/varnish-1.0.4.tar.gz

  [varnish-instance]
  recipe = plone.recipe.varnish:instance
  bind = 127.0.0.1:8082
  backends = 127.0.0.1:8080
  cache-size = 1G

これは以下の通りです。

  • メインのbuildout.cfgファイルを参照し、拡張し、そしてデプロイメントにもっと適した設定でそれを優先させます。
  • プライマリとセカンダリ(詳細はplone.recipe.zope2zeoserverとplone.recipe.zope2instanceを参照)の、2つのクライアントインスタンスとZEOサーバーをセットアップする。
  • Varnish cache server(詳細はplone.recipe.varnishを参照)をコンパイルする。

このようなbuildout構成ファイルを結合することによって、あなたは異なるデプロイメントシナリオに合わせたコンフィグレーションを作成できます。buildoutの高度な特徴についてもっと学ぶにはドキュメントを参照して下さい。この環境を作るには、あなたは設定ファイルを明示的に指定しなければなりません。

  $ ./bin/buildout -c deployment.cfg

ZopeとPloneを起動するには、、ZEOサーバー、2つのクライアント(あるいは少なくともプライマリ一つ)とVarnishサーバーをスタートする必要があるでしょう。

  $ ./bin/zeoserver start
  $ ./bin/primary start
  $ ./bin/secondary start
  $ ./bin/varnish-instance

recipeは(./bin/repozoの中の)ZODBバックアップと(./bin/zeopackの中の)データベースのパックのスクリプトも作成します。

さらなるオプション

zc.buildoutはとても柔軟性のあるシステムです。新しいrecipeを作るのが比較的簡単で、既存のrecipeを強力な方法で結合出来ます。Cheese Shopを捜して、"buildout"がより多くのrecipeを見つける、あるいはrecipeがどのように作成されたかを理解するにはPlone自身のrecipeのいくつかのソースコードを見てください。

ドキュメントアクション