### Navigation

- index
- modules
- toc
- next
- previous
- jmb.core 0.8.6 documentation »
- Setup e gestione progetti »

# Installazione con buildout

Scopo del setup illustrato qui di seguito è:

- Creare un workflow in cui il setup di un sito sia fulmineo, almeno per quanto riguarda il lavoro umano...
- Creare una setup isolato e riproducibile. Le librerie utilizzate devono essere sotto stretto controllo del programmatore
- Deve essere possibile derogare se necessario (ad esempio non vogliamo ricompilare il modulo ‘uno’ necessario per collegarsi a Libreoffice)

## Possibili alternative

le alternative possibili sono

1. virtualenv
2. buildout (ricca documentazione su pypi)

Mentre virtualenv risulta particolarmente efficace per l’isolamento, buildout risulta più pratico per la configurabilità. Noi useremo `buildout` e costruiremo dentro un virtualenv in modo automatico. Entrambi richiedono di compilare alcuni pacchetti quindi devono essere installati anche alcuni pacchetti dev.

Note

Buildout ha recentemente rilasciato un ramo >= 2.0 che NON possiamo usare in quanto la principale ricetta che usiamo (tl.buildout_virtual_python) non è stata ancora portata. O usiamo la 1.7.1 o la 1.5.2-sd.

## Buildout in pratica

L’installazione di jumbo e dei siti che lo usano viene fatta usando `buildout` nel seguente modo:

    hg clone http://hg.thundersystems.it/siti/www.mysite.it
    cd www.mysite.it
    python bootstrap.py
    bin/buildout
    dj    # equivalente a bin/django shell = ./manage.py shell

## Configurazioni una tantum

Questo semplice sistema prevede che siano state prese alcune precauzioni una volta nel sistema (non per ogni pacchetto/sito) e che sia stato personalizzato il sistema opportunamente. Il modo facile è installando il pacchetto `thunder-buildout` dai repositori argo ma raccomando di leggere anche l’installazione manuale dove spiego i vari componenti.

### installazione tramite pacchetto deb

Occorre installare il pacchetto `thunder-buildout` che è un pacchetto che contien pochi file ma molte dipendenze, ad esempio libreoffice che viene usato in molti progetti per produrre le stampe.

Note

al momento fa partire in automatico libreoffice all’avvio del pc, questo non è opportuno per i nostri pc personali e quindi verrà modificato a breve.

Aggiungere la sorgente argodef:

    echo deb http://apt.argolinux.org precise main >> /etc/apt/sources.list
    apt-get update
    apt-get install thunder-buildout

Attenzione che il pacchetto installa una situazione funzionante comprensiva delle seguenti configurazioni:

> - configurazione in `/root/.buildout` (leggi in seguito)

> - configurazione in `/home/www` (leggi sotto)

> - fornisce i comandi

>   dj: | interazione fondamental, equivalente a `manage.py` ma chiama Python nell’ambiente virtuale corretto e può essere chiamato da qualunque sottocartella del progetto. Utile anche per generare documentazione e fare upload della stessa dj dj
>   py: | chiama ip python dell ambiente virtuale
>   ipy: | chiama ipython dell’ambiente virtuale
>   jmb-test-setup: | utile strumento per testate quali pacchetti sono presenti nell’ambiente viutuale, generare i link ai repositori (vedi sotto), manipolare i repo sotto `.src`
>   jmb-start: | starter di ogni applicazione. Crea un progetto/applicazione nuovi a partire da un template che viene tenuto costantemente aggiornato a come vogliamo che siano i progetti/applicazioni
>   jmb-prepare: | crea i pacchetti e cura l’upload nel nostro repository pipy
>   jmb-go: | una script che permette un avvio rapido di progetti

## Struttura cartelle

Il comandi riportati sopra (file:python boostrap.py e file:bin/buildout) creano una struttura come la seguente:

    .
    |-- bin
    |    `--python         << eseguibile "isolato"
    |-- .develop-eggs       << egg-link ai sorgenti
    |-- parts
    |   |-- buildout
    |   `-- vpython        << virtual evironment
    `-- .src
        |-- jmb.core    <<  codice sorgente (hg clone ...)
        |-- ...

mentre altre eggs saranno depositate nella cartella indicata nella configurazionedi default `~/.buildout/default.cfg`.

Sotto `.src` troviamo tutti i sorgenti di cui è stato fatto il checkout, ovvero quei sorgenti richiesti nella configurazione. È possibile ed è lasciata libertà (dalla ricetta, non da me) di scegliere se sostituirlo con un link simbolico. Spesso è la cosa più opportuna e per sostiture tutti i link in un sol colpo potete usare il comando:

    jmb-test-setup -l

## buildout.cfg

buildout usa “ricette” ed “estensioni” per implementare le cose che vogliamo fare. Le ricette che ho scelto puntano a:

creare un ambiente isolato:
| questo è compito di tl.buildout_virtual_python, il compito è quello di fare in modo che il nostro ambiente non “veda” nessuna libreria di sistema in modo da essere sicuri che le librerie dichiarate in `setup.py` e in buildout.cfg siano le uniche necessarie.

creare ambiente per django:
| questo è compito di djangorecipe: crea un binario chiamato `django` che è l’equivalente di `manage.py` ma che ha già impostato il path nel modo corretto: ogni volta che avremmo suato `./manage.py` suiamo questo in alternativa per avere un `manage.py` che opera sullo stesso ambiente virtuale. Ad esempio:
    bin/django test
    bin/django runserver
    bin/django shell
djangorecipe crea anche una configurazione per wsgi che però è incompatibile con il virtualenv, vedi wsgi per leggere la soluzione.
usare i nostri sorgenti:
| questo è compito di mr.developer. Buildout può lavorare in modo `eggs` o `develop`. In sostanza per ogni libreria dichiarata in `${vpython:eggs}` verrà creata una voce di sys.path che punta ad una cartella egg.

Suggerisco di creare la configurazione iniziale con jmb-start, ma riporto un esempio di `buildout.cfg` che non è completo:

    [buildout]
    extends = thunder-buildout.cfg
    develop = .                  # dichiariamo la cartella corrente
                                 # come cartella in sviluppo

    parts = req django ipython
    extensions = mr.developer
    auto-checkout = *
    sources-dir = .src

    [vpython]                     # creiamo un ambiente isolato analogo
                                  # a quello creato da virtualenv

    recipe = tl.buildout_virtual_python
    eggs = tl.buildout_virtual_python
           cybergun
           jumbo-core
           jumbo-contacts
           jumbo-ecommerce

    extra-paths = ${thunder:extra-paths}
    site-packages = false          # come --no-site-packages di virtualenv

    [req]
    recipe = zc.recipe.egg
    python = vpython             # forza l'uso dell'ambiente virtuale
    eggs = babel
    interpreter = py

    [sources]
    # le sorgenti elencate qui sono automaticamnete messe
    # nelle develop-egg quindi disponibili senza bisogno di aggiungerle nelle egg
    jmb.core = hg ${thunder:jmb2}/jmb.core
    jmb.openvpn = hg ${thunder:jmb2}/jmb.openvpn

    [django]
    recipe = djangorecipe
    settings = tsettings
    eggs = django
    python = vpython
    absolute_path = True

    [ipython]
    recipe = zc.recipe.egg
    python = vpython
    eggs =  ipython

## setup.py

Tutto il sistema di packaging di Python si basa sulla configurazione contenuta in `setup.py` in particolare nella direttive:

name: | nome del pacchetto (es.: jumbo-core)
install_required:
| dipendenze esplicite del pacchetto:
    ['setuptools', 'xlwt', 'xlrd', 'django <= 1.2.7']
packages: | pacchetti messi a disposizione (es.: [‘admin_tools’, ‘jumbo’, ...]) nella maggior parte dei casi va bene il default scritto nel template usato da jmb-start:
    packages=find_packages(exclude=['tests', 'tests.*'])
version: | è la versione di un pacchetto, indispensabile per potere fissare le rel che veramente funzionano
package_data: | sono i file che devono essere inclusi nel pacchetto anche se non sono moduli python: file css, js, html, png e txt. Oltre che qui vanno segnalati anche in MANIFEST.in. Il progetto di default mostra lesempio di come fare questo. Nel setup.py di default è inclusa la funzione `get_data_files` per facilitare l’inclusione degli stessi.

Una esauriente introduzione al setup può essere letta qui

### Navigation

- index
- modules
- toc
- next
- previous
- jmb.core 0.8.6 documentation »
- Setup e gestione progetti »