Prima di tutto: usi ZopeSkel... vero?

La frase "non uso ZopeSkel perché sono abituato a fare le cose a mano" non è una scusa valida!

Personalmente uso ZopeSkel solo per la creazione iniziale dell'egg, poi non mi addentro mai molto nell'uso dei "paster subcommands" (ma non sempre... creare nuovi contenuti per Archetype è comodissimo), ma quello è sufficiente. Usare ZopeSkel per generare lo scheletro dei propri egg significa seguire la convenzione e lo standard!

Non mi addentro ulteriormente sull'argomento... se non usi ZopeSkel e sei incuriosito puoi leggere l'ottimo articolo che trovi su plone.it.

Le novità nascoste

Prima di tutto verifica di avere disponibile l'ultima versione (al tempo in cui scrivo siamo alla 2.17):

keul@redturtle:~$ sudo easy_install -U ZopeSkel

Notate innanzi tutto che il vostro sistema ha ora disponibile un secondo comando oltre al già conosciuto paster (hai letto l'articolo sopra, vero?). Il nuovo script è zopeskel.

Cosa fa? A cosa serve? E' principalmente una forma semplificata del primo script... diciamo un "paster for dummies", ma la vera comodità e fulcro di questo articolo è la possibilità di creare tramite lo script zopeskel un file di configurazione con alcune preferenze di default.
Possiamo finalmente usare paster e premere molte più volte "invio" (accettando la risposta predefinita) di quanto non venisse fatto fin'ora.

Lanciando la guida di zopeskel otteniamo questo:

keul@redturtle:~$ zopeskel --help
...
You can generate a starter .zopeskel file by running this script with
the --make-config-file option. This output can be redirected into
your ``.zopeskel`` file::

    bin/zopeskel --make-config-file > /path/to/home/.zopeskel
...

In pratica, nella nostra home possiamo ospitare un file con nome ".zopeskel" con alcune configurazioni predefinite e zopeskel stesso ci permette di generarne uno di esempio, con una sintassi valida, da personalizzare poi.

keul@redturtle:~$ zopeskel --make-config-file > ~/.zopeskel

Le opzioni non sono poche e forse un tantino esagerate. Potreste ad esempio avere configurazioni diverse a seconda del tipo di comando paster che state usando...
Io rimango per un uso semplice!

# This file can contain preferences for zopeskel.
# To do so, uncomment the lines that look like:
#    variable_name = Default Value

[DEFAULT]

expert_mode = all
version = 0.1.0
author = RedTurtle Technology
author_email = sviluppoplone@redturtle.net

[archetype]

# Expert Mode? (What question mode would you like? (easy/expert/all)?)
# expert_mode = easy
...

La sezione [DEFAULT] sarebbe solitamente vuota ma avete esempi completi in tutte le altre sezioni (una per ogni tipo di template paster disponibile) anche se tutte commentate.

Se come me volete configurare solo la sezione [DEFAULT], usate qualche copia incolla!

Quella postata qui sopra è esattamente la mia configurazione, che vado ad analizzare.

• expert_mode. E' un'opzione piuttosto nuova e il default sarebbe "easy"; è interessante perché permette di porre all'utente "meno domande"... ma visto che fingo di essere uno smanettone, preferisco che mi venga chiesto "tutto".
  Scherzi a parte, alcune delle domande che vengono saltate le trovavo invece importanti.
• version. La versione del prodotto. Il default è 1.0, ma personalmente preferisco 0.1.0, ben considerando che paster viene usato alla creazione... è molto probabile che la prima release del vostro super prodotto non sia tanto super... e che sia di qualità alpha o beta.
• author. Nel mio sistema, a lavoro, è normale che il codice sviluppato sia della mia Azienda. Niente più scrittura a mano del nome dell'Azienda e niente più differenze tra me e il mio collega.
• email. Di nuovo convenzione (un unico indirizzo aziendale per lo sviluppo plone)... ma potrei specificare la mia email personale!

Teniamo comunque presente che questi valori sono solo i default. La gestione dell'eccezione è sempre possibile (non diventate troppo pigri ... potete sempre cancellare la risposta che paster sta proponendo e scrivere da capo... come poi avrete fatto fin'ora!).

Un file .zopeskel in ogni azienda

Perché no? Pensare che ogni sistema per sviluppatori all'interno di un'azienda abbia questa configurazione porta uniformità al rilascio di codice alla comunità. Non sto ovviamente parlando delle prime opzioni che abbiamo illustrato, che sono più che altro preferenze davvero personali.

Potrebbe non essere il vostro caso, magari la Vostra Azienda preferisce mantenere come autore lo sviluppatore stesso (oppure mettere sempre come autore il nome del capo programmatore che vive sulle vostre spalle e che vi ruba la fama). Altre magari vorranno che tutto il codice risulti fatto dall'Azienda, ma potrebbe voler mantenere la Vostra e-mail (così che siate voi ad essere disturbati in caso di problemi).

Questo, come dicevo è come il mio sistema è configurato qui in RedTurtle... a casa mia ho un PC che ogni tanto uso per i miei personali progetti Plone. Ovviamente anche là uso paster ma in una configurazione diversa!

Provate anche voi. E' comodo...

Prima di tutto: "-N" è vostro amico!

I problemi li vediamo sotto, ma ricordate che l'opzione -N su un vecchio Plone come può essere la versione 3.1 è un parametro vivamente consigliato!

Volete installare un nuovo prodotto?
Ricordate che "-N" sta per non-updating, quindi solo gli egg già scaricati non vengono aggiornati, ma se la vostra modifica all'istallazione richiede la presenza di un nuovo modulo, questo viene normalmente prelevato (...e speriamo che la versione scaricata sia compatibile... in caso contrario, cercatene una che lo sia! vedere sotto...).

Di chi è la colpa?

I problemi sono iniziati con qualche prodotto rilasciato nell'era Plone 3.3, ma la cosa è diventata particolarmente sensibile (e fastidiosa) col rilascio delle prime versioni egghizzate di Plone 4.

Plone 3.1 non aveva le versioni degli egg fissate dai file versions (e.g: http://dist.plone.org/release/3.3.1/versions.cfg per Plone 3.3.1).

Per di piu "Plone" e "Zope2" sono diventati "veri" egg da poco.

Iniziano quindi ad essere disponibili molti egg che (giustamente) richiedono dipendenze da questi moduli software...

...peccato che a loro volta questi abbiano dipendenze verso altri egg che sono troppo aggiornati per la vecchia versione di Plone 3.1.

NB: l'idea non è sbagliata di per se! In un mondo perfetto se un utente che non sa nulla di Zope & Plone naviga la rete e trova il riferimento ad un prodotto che si chiama Ploneboard e che fornisce un forum, potrebbe volerlo provare. Se tenta di installarlo con easy_install, perché questo non dovrebbe a sua volta scaricarmi un ambiente Plone completo?

Vediamo di risolvere

Diciamo che state leggendo questo perché vi siete dimenticati di tenere l'opzione "-N", oppure un nuovo prodotto che dovete per forza installare ha delle dipendenze pericolose, o siete masochisti...

Ad ogni modo (i gusti son gusti) eccovi un esempio di un buildout di un Plone 3.1 che di recente mi ha dato problemi.

[buildout]
parts =
    plone
    zope2
    instance
    zopepy
    fss

# Add additional egg download sources here. dist.plone.org contains archives
# of Plone packages.
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
eggs =
    elementtree
    iw.fss>=2.7.5,<2.7.6dev
    iw.recipe.fss
    Products.DocFinderTab
    
# Reference any eggs you are developing here, one per line
# e.g.: develop = src/my.package
develop =
    ...

[plone]
recipe = plone.recipe.plone

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

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

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 = 
    iw.fss
    iw.fss-meta
    ...

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

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

[fss]
recipe = iw.recipe.fss
storages =
    ...

Trovate degli omissis per alcune parti generiche e non interessanti.

Qual'è l'effetto di lanciare un buildout con questo .cfg, tenendo conto delle recenti dipendenze degli egg con Plone e Zope2?
Una frittata... e non particolarmente piacevole.

Ecco cosa potreste leggere a console (usate l'opzione "-v" per individuare gli errori):

...
Installing 'plone.recipe.zope2instance'.
We have the best distribution that satisfies 'plone.recipe.zope2instance'.
Picked: plone.recipe.zope2instance = 4.0a2
Getting required 'Zope2>=2.12.1'
  required by plone.recipe.zope2instance 4.0a2.
We have no distributions for Zope2 that satisfies 'Zope2>=2.12.1'.
...

In pratica, l'aggiornamento prova a scarica l'ultima versione di plone.recipe.zope2instance, ma dall'uscita di Plone 4 l'ultima versione risulta essere la 4.0a2. Questo va già male di per se, ma come accennato sopra un altro grosso problema è che questo è dipendente dall'egg Zope2 versione 2.12.1.
Inutile proseguire oltre; a sua volta questo egg ha un'infinità di altre dipendenze... vediamo dove porta tutto questo:

Getting distribution for 'Zope2>=2.12.1'.
Running easy_install:
/opt/local/bin/python "-c" "from setuptools.command.easy_install import main; main()" "-mUNxd" "/Users/luca/Library/Buildout/eggs/tmpFz8U_N" "-q" "/Users/luca/Library/Buildout/downloads/dist/Zope2-2.12.1.tar.gz"
path=/Users/luca/Library/Buildout/eggs/setuptools-0.6c11-py2.4.egg

src/initgroups/_initgroups.c: In function ‘initgroups_initgroups’:
src/initgroups/_initgroups.c:34: warning: implicit declaration of function ‘initgroups’
  File "build/bdist.macosx-10.6-i386/egg/Zope2/Startup/zopectl.py", line 313
    finally:
          ^
SyntaxError: invalid syntax
  File "/Users/luca/Library/Buildout/eggs/tmpFz8U_N/Zope2-2.12.1-py2.4-macosx-10.6-i386.egg/Zope2/Startup/zopectl.py", line 313
    finally:
          ^
SyntaxError: invalid syntax
While:
  Installing.
  Getting section instance.
  Initializing section instance.
  Installing recipe plone.recipe.zope2instance.
  Getting distribution for 'Zope2>=2.12.1'.
Error: Couldn't install: Zope2 2.12.1

Questo non è l'unico errore possibile, ma spieghiamolo: Plone 4 userà Python 2.6 e la sintassi non è completamente compatibile con Python 2.4 usato fino alla versione 3.3.

In altri casi invece il problema è un conflitto di dipendenze: ad esempio Plone 3.1 ha già un egg Zope2, la cui versione è la 0.0.

Questo perché nei buildout di Plone vengono usati (e possono essere usati anche per i vostri scopi) i fake-eggs. Un fake egg non è un vero e proprio egg ma il buildout crede di averlo disponibile alla versione (di solito) 0.0.

In un modo o nell'altro, il buildout non arriva a conclusione...

Come risolvere

La prima regola è analizzare gli errori; lanciare quindi il buildout con l'opzione "-v" per avere messaggi dettagliati, poi risalire la catena delle dipendenze nella console e trovare chi tra questi egg sta scaricando "Zope2>2.12.1" (oppure altri egg non appropriati perché rilasciati per Plone 4).

Nell'esempio sopra il problema era plone.recipe.zope2instance. Ci possono essere altri egg maledetti (ne vediamo almeno un altro più avanti) a seconda dei prodotti usati nel vostro buildout.

La soluzione è fissare le versioni:

[buildout]
parts =
    plone
    zope2
    instance
    zopepy
    fss

versions=versions

# Add additional egg download sources here. dist.plone.org contains archives
# of Plone packages.
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
eggs =
    elementtree
    iw.fss>=2.7.5,<2.7.6dev
    iw.recipe.fss
    Products.DocFinderTab
    
# Reference any eggs you are developing here, one per line
# e.g.: develop = src/my.package
develop =
    ...

[versions]
plone.recipe.zope2instance = 3.6
...

La nuova parte versions, usata esplicitamente nella parte buildout, fissa plone.recipe.zope2instance alla "vecchia" versione 3.6.
Non ho una regola per trovare la versione giusta... andare alla pagina del Cheeseshop e guardare la sezione CHANGES di questo egg è stato sufficiente. La 3.6 è la main release precedente alla 4.0.

Questo potrebbe essere sufficiente... in presenza di altri egg velenosi si può ricorrere all'uso esplicito degli additional-fake-eggs.

Alcuni egg ad esempio hanno una dipendenza da "Plone" (la cui vita come egg, ricordo, è iniziata con la versione 3.2).

Ecco come modificare la parte zope2 per sistemare la dipendenza a Plone:

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

In questo modo il nostro buildout avrà già disponibile un egg "Plone" alla versione 0.0.

I problemi rimangono in vari casi. Cosa succedere ad esempio se voglio usare une prodotto che ha una dipendenza ad una versione precisa di un egg che ho nella sezione fake-eggs? Ad esempio: Ploneboard versione 2.1beta2 ha una sezione di dipendenze così fatta (preso dal suo setup.py):

      install_requires=[
        'setuptools',
        'Products.SimpleAttachment',
        'plone.app.controlpanel',
        'plone.app.portlets',
        'plone.portlets',
        'plone.memoize',
        'plone.i18n',
        'python-dateutil',
        'Plone >= 3.3',
      ],

Anche lanciando il nostro buildout con opzione "-N" e con la presenza del fake-egg "Plone", buildout prova giustamente ad ottenere una versione di "Plone>= 3.3". La versione 0.0 ovviamente non va bene.

La sezione fake-eggs ha una potenzialità maggiore; potrei cambiare il buildout così:

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

Questo significa che il nostro fake-egg "Plone" non sarà più a versione 0.0

NB: ovviamente non è detto (e non ho testato) che provare questa versione di Ploneboard, fatta per Plone 3.3 su un Plone 3.1, porti a qualche risultato funzionante... spero che passi il concetto generale dell'esempio!

Un ulteriore esempio

Ora voglio anche usare in questo vecchio buildout un file .cfg per lo sviluppatore, magari copiato da altri buildout. Questo aggiunge alcuni egg molto utili per lo sviluppo in locale:

[buildout]
extends = buildout.cfg

parts+=
    omelette

[instance]
http-address = 8080
eggs +=
    plone.reload==1.1

zcml +=
    plone.reload

[omelette]
recipe = collective.recipe.omelette
eggs =
    ${instance:eggs}

products =
    ${instance:products}

Se lancio il buildout senza l'opzione "-N" torno ad avere problemi:

./bin/buildout -vc sviluppo.cfg

Ottengo questo:

While:
  Installing instance.
Error: There is a version conflict.
We already have: Zope2 0.0
but Products.CMFCore 2.2.0-beta requires 'Zope2>=2.12.0b4dev'.

Come abbiamo già fatto: chi è che sta provando a scaricare Products.CMFCore 2.2.0-beta (anche CMF non era egghizzato fino a poco tempo fa)?

Analizzando indietro il trace, troviamo che il cattivo è plone.reload:

Getting required 'Products.CMFCore'
  required by plone.reload 1.1.
We have the best distribution that satisfies 'Products.CMFCore'.
Picked: Products.CMFCore = 2.2.0-beta

Possiamo di nuovo superare la cosa tramite fake-eggs, oppure fissando la versione di plore.reload ad una versione più vecchia, compatibile con Plone 3.1.

Nel primo caso modifico buildout.cfg di nuovo, come segue:

additional-fake-eggs =
    Products.CMFCore 
    Plone=3.3

Anche in questo caso forse sto barando... ma non è detto (vedere sotto).

Il modo canonico è come sempre trovare una versione compatibile; rimuovo il fake-egg "Products.CMFCore" e questa volta modifico sviluppo.cfg:

[instance]
http-address = 8080
eggs +=
    plone.reload<1.1dev

E con questo abbiamo finito!

Quale modo è il migliore?

In generale, fissare le versioni è la giusta soluzione, e con l'uso di versions si sta facendo quello che le release successive di Plone hanno fatto.

L'uso dei fake-eggs è comunque una scappatoia da non dimenticare... Magari Ploneboard 2.1 funziona anche con Plone 3.1... solo che nessuno lo ha mai testato (e potreste volerlo fare voi).

Lo stesso per plone.reload. La versione successiva (la 1.2) ha rimosso la dipendenza all'egg Products.CMFCore. Magari anche la 1.1 funziona correttamente con il nostro vecchio Plone e gli sviluppatori si sono accorti di come questa dipendenza creasse più problemi che altro.