Terminologia

Prima di iniziare, chiariamo il significato di alcuni termini

Installazione Zope

Quanto ottenuto scaricando e compilando Zope, o usando una delle distribuzioni binarie di Zope.

Software home (variabile ambiente $SOFTWARE_HOME)

Dentro l'installazione Zope, la cartella lib/python contiene tutto il codice Python del nucleo dell'application server Zope, noto come software home. I vari pacchetti Zope 3 sono distribuiti qui.

Instanza Zope

Una installazione Zope può supportare molte istanze. Lo script mkzopeinstance.py nell'installazione Zope è usato per creare nuove istanze. Ogni istanza ha uno script di controllo per avviare e fermare il servizio, un file di configurazione zope.conf, una cartella Products, e un file Data.fs che contiene lo ZODB. In questa guida faremo in modo che buildout generi e configuri una istanza Zope per noi.

Instance home (variabile ambiente $INSTANCEHOME)

Il path dell'istanza Zope corrente.

Path Python (variabile ambiente $PYTHONPATH, nota anche come sys.path)

L'interprete Python cercherà moduli in una o più cartelle, note come path Python. Quando Zope è in esecuzione, questo normalmente comprende i moduli Python globali che fanno parte della library standard, la cartella site-packages dell'interprete, dove sono installati moduli ed egg di estensione "globali", la software home di Zope, e la cartella lib/python nella instance home.
In questa guida vedremo in che modo buildout aggiunge un certo numero di egg specifiche al path Python, addirittura in fase di esecuzione.

Pacchetto Python

Un termine generico che descrive un modulo Python ridistribuibile. Nella forma più semplice, un pacchetto è una cartella con un file __init__.py  e del codice Python.

Prodotto Zope

Un tipo speciale di pacchetto Python usato per estendere Zope. Nelle vecchie versioni di Zope tutti i prodotti erano cartelle all'interno della cartella speciale Products di una istanza Zope, e avevano il nome del modulo Python che inizia con "Products". Per esempio, il nucleo di Plone è un prodotto chiamato CMFPlone, noto in Python come Products.CMFPlone.

Egg Python

Un modo di impacchettare e distribuire pacchetti Python. Un Egg contiene un file setup.py con metadati quali il nome e la mail dell'autore e le informazioni di licenza, come pure informazioni relative alle dipendenze. setuptools, la libreria Python che potenzia il meccanismo degli egg, è capace di trovare e scaricare automaticamente le dipendenze per le egg che installi. E' perfino possibile per due egg diverse usare versioni diverse della stessa dipendenza. Le Egg supportano anche una funzione nota come entry points, una sorta di meccanismo di plug-in generico. Non parleremo degli extension points in dettaglio durante questo tutorial, ma potrai leggere altro a riguardo (e altre funzionalità degli egg) sul sito PEAK.

Il Cheese Shop (noto anche come PyPI, Python Package Index)

Il Cheese Shop è un indice che ospita migliaia di pacchetti Python. Puoi navigarlo se sei in cerca di un pacchetto specifico. Ancora più importante, setuptools (e buildout, e lo script easy_install) può interrogare questo indice per scaricare e installare automaticamente egg.

 easy_install

Uno script per la shell che può essere usato per cercare nel Cheese Shop e installare pacchetti nell'ambiente Python globale. Lo utilizzeremo solo per installare alcuni pacchetti globali, dato che buildout gestisce le egg per noi in modalità locale ad ogni progetto  buildout, evitando ambiguità di versione globali.

Pacchetto Namespace

Una funzionalità di setuptools che rende possibile distribuire pacchetti multipli e separati condividendo un singolo namespace di primo livello. Per esempio, i pacchetti plone.theme e plone.portlets condividono entrambi lo stesso namespace di primo livello "plone", ma sono distribuiti con egg separati. Quando vengono installati, ogni egg vive nella sua cartella (o in alternativa in una archivio compresso di quella cartella). Senza pacchetti namespace, dovremmo distribuire un unico pacchetto Plone gigante, con una cartella Plone di primo livello contenente tutti i possibili figli, come ad esempio plone/theme e plone/portlets.

Il namespace magico Products

Quando Zope trova un "prodotto", crea una voce in Control_Panel/Products nella root della ZMI, ed esegue il metodo initialize(), che trova nel file __init__.py nella root del prodotto, ogni volta che Zope si avvia. Non tutti i pacchetti usati in un contesto di Plone devono essere prodotti, ma alcune caratteristiche proprie dei prodotti veri e propri sono richieste per:

• i profili di GenericSetup
• cartelle Skin installate come layer nel tool portal_skins (ma non per i browser view in stile Zope 3)

Il modo più semplice di creare un prodotto è di farne una cartella nella cartella Products di una istanza (o buildout). Ad ogni modo, fino a Zope 2.11 (che trasforma il namespace Products.* in un pacchetto namespace corretto), non possiamo distribuire prodotti sotto forma di egg. Inoltre molti sviluppatori trovano poco naturale mantenere tutto in un singolo namespace "piatto".

E' possibile usare pacchetti (inclusi quelli distribuiti con gli egg) fuori dalla cartella/namespace Products come prodotti Zope 2. Per fare questo dobbiamo aggiungere una linea come la seguente al file configure.zcml del pacchetto:

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

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

</configure>

In secondo luogo è importante capire che i pacchetti fuori dal namespace Products non sono rilevati automaticamente all'avvio di Zope. Se contengono file configure.zcml (come faranno la maggior parte dei pacchetti), questi dovranno essere esplicitamente inclusi in qualche modo. Ciò potrebbe essere fatto tramite:

• il file configure.zcml di un altro pacchetto;
• site.zcml di Zope, la radice di tutti i file ZCML, che si trova nella cartella etc nella instance home;
• uno "slug" ZCML, un file monoriga creato nella cartella etc/package-includes dell'istanza Zope, con un nome del tipo my.package-configure.zcml.

In ogni caso, la sintassi è la stessa:

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

Se hai i file meta.zcml o overrides.zcml, puoi aggiungere direttive <include /> per tali pacchetti, ottenendo lo stesso effetto. Se usi gli slug, devono essere nominati allo stesso modo, ad esempio my.package-meta.zcml o my.package-overrides.zcml. Uno slug non può contenere più di una linea.

Più avanti in questa guida mostreremo come buildout può gestire gli slugs per noi automaticamente.