Buildout-Konfiguration¶

Die base.cfg-Datei gliedert sich in die folgenden Abschnitte:

[buildout]

Hier werden die globalen Einstellungen für diesen Buildout angegeben.

parts

Die in dieser Konfiguration angegebenen Abschnitte, die in der angegebenen Reihenfolge durchlaufen werden:

parts =
    instance-base
    zopepy
    i18ndude
    zopeskel

extends

Eine bestehende Buildout-Konfiguration wird erweitert, nämlich http://dist.plone.org/release/4.3/versions.cfg und versions.cfg.

find-links

URLs, Datei- oder Verzeichnisnamen, in denen Buildout nach Links zu Distributionen suchen soll.

extensions

Erweiterungen, die den Funktionsumfang von Buildout vergrößern:

allow-picked-versions

Mit dem Wert false kann gewährleistet werden, dass alle Versionen festgeschrieben wurden.

versions

Es wird auf einen Abschnitt verwiesen, in dem die Versionen der Python-Packages festgeschrieben werden können, in unserem Fall ist der Abschnitt versions genannt worden. Weiter Hinweise zur Verwaltung von Versionen erhalten Sie in Aktualisierung und Versionierung.

unzip

Üblicherweise packt Buildout keine gezippten Python Eggs aus.

[instance-base]

Dieser Abschnitt erstellt und konfiguriert eine Zope-Instanz unter Verwendung von plone.recipe.zope2instance:

[instance-base]
recipe = plone.recipe.zope2instance
user = admin:admin
http-address = 8080
debug-mode = on
verbose-security = on
blob-storage = var/blobstorage

eggs =
    Plone
    Pillow

zcml =

environment-vars =
    PTS_LANGUAGES en de
    zope_i18n_allowed_languages en de
    zope_i18n_compile_mo_files true

eggs

Hier können zusätzliche Python-Eggs angegeben werden, wobei elementtree von Plone benötigt wird. Auf diese Eggs wird später in [instance] verwiesen.

Es können auch spezifische Versionen angegeben werden. Soll z.B. SQLAlchemy 0.3 installiert werden, sieht der Eintrag so aus:

eggs =
    ...
    SQLAlchemy>=0.3,<0.4dev

Auch die in diesem Projekt entwickelten Eggs werden hier angegeben:

eggs =
    ...
    my.package

develop =
    src/my.package

verbose-security

Damit lässt sich angeben,

Für welche Objekte wurde der Zugriff verweigert?
Welche Rechte sind notwendig?
Welche Rollen und Rechte sind den Objekten und Eigentümern zugeteilt?
Welches sind die wirksamen Proxy-Rollen?

Damit wir alle unauthorized-Ereignisse auch im Fehlerprotokoll angezeigt bekommen, müssen wir später im Site Error Log im Zope Management Interface (ZMI) der Plone-Site Unauthorized aus der Liste Ignored exception types entfernen.

eggs

Hier geben wir die der Instanz zur Verfügung stehenden Eggs an. In unserer Konfiguration werden die in den buildout- und plone-Abschnitten angegebenen Eggs verwendet.

zcml

Da die Konfigurationsdateien nicht automatisch für ältere Eggs oder Pakete geladen werden, kann Buildout angewiesen werden, einen sog. ZCML slug in parts/instance/etc/package-includes zu erstellen, indem die entsprechenden Pakete unter dieser Option aufgelistet werden:

zcml =
    my.package

Es kann auch explizit angegeben werden, welche Art von ZCML slug erstellt werden soll, z.B.:

zcml =
    my.package-overrides
    my.package-meta

overrides

Dies erstellt eine *-overrides.zcml-Datei in myproject/parts/instance/etc/package-includes/, mit der sich eine per zcml angegebene Konfiguration wieder überschrieben wird.

Anschließend wird in der configure.zcml-Datei von my.package eine overrides-Konfigurationsdatei eingefügt:

<includeOverrides file="overrides.zcml" />

Diese overrides.zcml-Datei enthält dann die Ersetzung einer bestehenden Konfiguration.

meta

Dies erstellt eine *-meta.zcml-Datei in myproject/parts/instance/etc/package-includes/, die gewährleistet, dass die gesamte Konfiguration dieses Pakets zur Verfügung steht bevor die weiteren zcml-Anweisungen abgearbeitet werden.

Weitere Konfigurationsoptionen von plone.recipe.zope2instance sind:

default-zpublisher-encoding

Liefert ein Request eine Unicode-Antwort und ist für ZPublisher.HTTPResponse kein spezifischer Zeichensatz angegeben, dann wird der Unicode-String mit dem default-zpublisher-encoding kodiert.

Der Standardwert ist utf-8.

zope-conf

Ein relativer oder absoluter Pfad zu einer Zope-Konfigurationsdatei. Eine zope.conf-Datei wird dann mit den Angaben in diesem Abschnitt generiert in parts/instance/etc/zope.conf.

zope-conf-additional

Sollen nur die Werte einiger Attribute der zope.conf-Datei geändert werden, können diese in zope-conf-additional angegeben werden. Dabei müssen die nachfolgenden Zeilen eingerückt sein.

environment-vars

definiert Umgebungsvariablen zur Laufzeit von Zope, z.B.:

environment-vars =
    zope_i18n_compile_mo_files = true

Einen vollständigen Überblick über alle Optionen des [instance]-Abschnitts erhalten Sie in plone.recipe.zope2instance.

[zopepy]

In diesem Abschnitt wird ein Python-Interpreter definiert, der alle Eggs und Pakete, aber keine Zope2-Produkte enthält und sich daher gut zum Debuggen und Testen eignet:

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

Mit dem Rezept wird das ./bin/zopepy-Skript erstellt und sowohl die Eggs aus dem [instance]-Abschnitt als auch die Zope-Module aus parts/zope2/lib/python der Zope-Installation eingeschlossen. Es muss also nicht mit jedem neuen Buildout-Projekt auch die PYTHONPATH-Umgebungsvariable neu gesetzt werden. Mit zopepy sollte sich z.B. auch einfach das Modul PageTemplates aus Products importieren lassen:

$ ./bin/zopepy
>>> from Products import PageTemplates

Da kein Fehler für den Import angegeben wurde, wird das Modul geladen, und der Python-Interpreter kann mit Strg-D (unter Windows Strg-Z) wieder verlassen werden.

`annotate`¶

Mit der Buildout-Option annotate werden alle Abschnitte alphabetisch sortiert angezeigt. Innerhalb jedes Abschnitts werden alle Schlüssel-Wert-Paare zusammen mit der Quelle angezeigt. Eine solche Quelle kann entweder ein Dateiname oder die Variablen COMPUTED_VALUE, DEFAULT_VALUE oder COMMAND_LINE_VALUE sein. Die Ausgabe kann z.B. folgendermaßen aussehen:

$ ./bin/buildout -c deploy.cfg  annotate
Setting socket time out to 3 seconds.

Annotated sections
==================

[backup]
enable_snapshotrestore= false
    /home/veit/sandboxes/vs_buildout/deploy.cfg
...
[buildout]
...
develop-eggs-directory= develop-eggs
    DEFAULT_VALUE
directory= /home/veit/vs_buildout
    COMPUTED_VALUE
...

annotate kann auch genutzt werden um herauszufinden, welche Version aufgrund welcher Konfiguration verwendet wird, z.B.:

[versions]
...
six= 1.2.0
    /home/veit/vs_buildout/plone-versions.cfg
...

Plone 3.2¶

Für Plone 3.2 sieht die Buildout-Konfigurationsdatei etwas anders aus. Sie gliedert sich in die folgenden Abschnitte:

parts =
    zope2
    productdistros
    instance
    zopepy

[zope2]

Dieser Abschnitt lädt und erstellt Zope 2 aus der im Abschnitt plone angegebenen URL:

[zope2]
recipe = plone.recipe.zope2install
fake-zope-eggs = true
additional-fake-eggs =
    ZODB3
url = ${versions:zope2-url}

Mit dem Rezept wird Zope 2 in parts/zope2 installiert, die Variable ZOPE_HOME ist also parts/zope2 und die Variable SOFTWARE_HOME parts/zope2/lib/python.

fake-zope-eggs

Falls der Wert auf true gesetzt wird, werden Links auf die Zope-3-Bibliotheken gesetzt. Wenn nun ein Egg in seiner setup.py-Datei auf ein zope.*-Egg verweist, finden die setuptools diese in /parts/zope2/lib/python/zope/ und installieren nicht erneut Versionen dieser Eggs in womöglich inkompatiblen Versionen. Ab Version 3 ist der Standardwert auf true gesetzt.

additional-fake-eggs

Hiermit lasst sich eine Liste zusätzlicher fake eggs angeben, wobei nur Python-Packages angegeben werden sollten, die sich auch in PYTHONPATH befinden. Der Standardwert schließt Acquisition, ClientForm, DateTime, docutils, ExtensionClass, mechanize, Persistence, pytz, RestrictedPython, tempstorage, ZConfig, zLOG, zodbcode, ZODB3, zdaemon und Zope2 ein.

Die Versionen von additional-fake-eggs lassen sich einfach angeben, z.B.:

additional-fake-eggs =
    ZODB3 = 3.7.1
    zope.annotation = 3.3.2

Wird keine Version für additional-fake-eggs angegeben, haben die faked eggs immer die Version 0.0.

skip-fake-eggs

Hier kann eine Liste von Packages angegeben werden, für die keine Fake eggs erstellt werden sollen. Somit können neuere Versionen spezifischer Zope-Packages installiert werden auch wenn fake-zope-eggs = true gesetzt ist, z.B.:

[buildout]
versions = versions

[versions]
zope.app.catalog = 3.5.2
zope.component = 3.5.1
zope.i18n = 3.6.0
zope.sendmail = 3.5.1
zope.testing = 3.7.1
five.intid = 0.3.0

[zope2]
fake-zope-eggs = true
additional-fake-eggs =
    ZConfig
    ZODB3
    pytz
skip-fake-eggs =
    zope.component
    zope.i18n
    zope.sendmail
    zope.testing

url

Die URL, unter der Zope heruntergeladen werden kann, in unserem Fall wird auf die versions.cfg-Datei verwiesen und den dort angegebenen Wert für zope2-url.

[productdistros]

Der Abschnitt kann verwendet werden, um Archive von Produkten herunterzuladen und zu installieren, z.B.:

urls =
    http://www.zope.org/Members/shh/DocFinderTab/1.0.2/DocFinderTab-1.0.2.tar.gz

nested-packages

Archive, die mehrere Zope2-Produkte enthalten.

Im folgenden Beispiel soll PloneLDAP 1.0 installiert werden:

[productdistros]
recipe = plone.recipe.distros
urls =
    http://plone.org/products/ploneldap/releases/1.0/PloneLDAP-bundle-1.0.tar.gz
nested-packages =
    PloneLDAP-bundle-1.0.tar.gz
version-suffix-packages =

Nach dem Aufruf von ./bin/buildout finden sich die Produkte LDAPMultiPlugins, LDAPUserFolder und PloneLDAP in parts/productdistros.

version-suffix-packages

Produkte, deren Verzeichnisnamen die Version enthält und die daher vor ihrer Verwendung umbenannt werden müssen.

In den Abschnitten products in [instance] wird dann auf den Installationsort von productdistros verwiesen:

${productdistros:location}

[instance]

Dieser Abschnitt erstellt und konfiguriert eine Zope-Instanz unter Verwendung von plone.recipe.zope2instance:

[instance]
recipe = plone.recipe.zope2instance
zope2-location = ${zope2:location}
...
products =
    ${buildout:directory}/products
    ${productdistros:location}

zope2-location: Es wird das im zope2-Abschnitt angegebene Verzeichnis für die Zope2-Installation verwendet.

Plone 3.1¶

Für Plone 3.1 sieht die buildout.cfg-Datei etwas anders aus:

[buildout]
parts =
...
plone

index

URL eines Index-Servers. In diesem Index sucht Buildout sofern in den unter find-links angegebenen Distributionen nichts gefunden wurde.

Ohne spezifische Angabe für index wird der Python Package Index verwendet. Aus Gründen der Stabilität und Performance kann sich jedoch ein anderer Index empfehlen:

index = http://download.zope.org/ppix

[plone]

verwendet plone.recipe.plone um die Plone Produkte und Eggs herunteruladen:

[plone]
recipe = plone.recipe.plone

Dabei ist zu beachten, dass immer die aktuellste Version verwendet wird. Soll immer nur ein Plone-3.1.x-Release verwendet wird, wird beim Erstellen des Buildout-Projekts zunächst auf die Frage Enter plone_version mit 3.1 geantwortet, und anschließend kann man sich zunutze machen, dass die Versionsnummern des plone.recipe.plone immer mit denen von Plone übereinstimmen:

recipe = plone.recipe.plone>=3.1,<3.2dev

Und für ein bestimmtes Plone-Release sieht die Angabe so aus:

recipe = plone.recipe.plone==3.1.7

Das plone-Rezept gibt jeweils passende Zope-Versionen, Produkte und Eggs an, die in den Abschnitten [zope2] und [instance] mit den Buildout-Variablen ${plone:zope2-url}, ${plone:eggs} und ${plone:products} referenziert werden.

Buildout-Konfiguration¶

annotate¶

Plone 3.2¶

Plone 3.1¶

`annotate`¶