### Navigation

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

# Utilities

## jmb-start

Per rendere più facile ed immediato partire con un nuovo progetto, ed in attesa di creare un vero sistema di templating, ho creato una semplice script che prende un mini-template per un progetto ed inserisce già la configurazione per `buildout.cfg`, `setup.py`, `MANIFEST.in` ed una intera struttura. Per un progetto sarà:

    jmb-start -t cms -vbm nome-progetto

o alternativamente per una app:

    jmb-start -t japp jmb.miapp

es:

    jmb-start -t japp jmb.timereport

Volendo aggiungere la struttura buildout ad un progetto esistente è possibile usare l’opzione `-e`, questa sovrascrive i file esistenti (che sono sicuramente sotto controllo di versione), rendendo immediato capire cosa va fatto per aggiornare il progetto/applicazione esistente all’ultma versione del relativo template

È importante scrivere le dipendenze per ogni project/application direttamente nel `setup.py` come scritto sopra piuttosto che nel file `buildout.cfg` così che vengano correttamente ereditate da ogni altro progetto che dichiari questo come dipendenza. Le dipendenze espresse in `buildout.cfg` devono servire o per integrare pacchetti di terze parti non ben configurate (es.: manca dipendenza da PIL in `sorl-thunmbnail`) o per imporre una determinata versione, nel qual caso occorre usare la sezione `[versions]` (attenzione al case):

    [versions]
    Django == 1.4.3-sd
    django == 1.4.3-sd   # mi pare siano letti solo in minuscolo

`jmb-start` copia anche una versione di `.hgignore`, ed un tsettings.py che viene usato come default, sta a voi correggere a mano.

## dj

il comando di gran lunga più utilizzato sarà `bin/django` che è l’equivalente di `manage.py`. Con lo script `dj` sarà possibile chiamarlo anche da sottocartelle del progetto nel modo corretto. Senza argomenti è equivalente a `bin/django shell`.

La documentazione può essere prodotta da:

    dj docs

e può essere uploadata sul sito ufficiale con:

    dj -u docs   # nota l'opzione prima del pacchetto!!!

Leggere l’help prodotto da `dj -h` per ulteriori scorciatoie.

## py

Lancia l’interprete Python dell’ambiente virtuale. Analogamente a `dj`, `py` chiama bin/py in ogni sotto cartella

## ipy

Lancia l’interprete IPython dell’ambiente virtuale. Utile quando `dj` non parte per problemi di configurazione di `django`. Analogamente a `dj`, `ipy` chiama bin/py in ogni sotto cartella

## jmb-test-setup

Questa script permette di mostrare quali versione dei pacchetti sono incluse nell’ambiente virtuale.

## jmb-prepare

Questa script permette di testare una aspetto della configurazione che può facilmente sfuggire: che siano inclusi nella distribuzione i file di dati, ovvero quelli che non sono moduli python: css, html, png, js, txt. Crea una distribuzione binaria e controlla quali file vengono effettivamente inclusi. I file inclusi sono controllati da MANIFEST.in e dalla apposita funzione get_data_files in setup.py.

Le opzioni -m e -b permettono di creare la distro binaria e sorgente e di metterla nella cache di buildout (vedi help):

    jmb-prepare -m    # crea .tar.gz nella cache locale
    jmb-prepare -u    # carica in pypi.thundersystems.it (via ssh)
    jmb-prepare -b    # crea egg per locale

## jmb-go

Questa banale script esegue una serie di piccole operazioni che portano il repo appena clonato o generato a funzionare:

    dj syncdb --all --noinput
    dj migrate --all --fake
    dj createsuperuser --username $SUPERUSER --email $EMAIL
    dj collectstatic --noinput $LINK

## jmb-sync

Questa script permette di sincronizzare un db remoto in uno locale facendo un dump del remoto, un eventuale dump del locale ed usando rsync fra i due, in questo modo è estremamente efficace.

Si basa su un file di configurazione (`.sync`) nella cartella del progetto e NON legge la configurazione dai settings di django ed opera solo via ssh (quindi è necessario avere la chiave di root sulla macchina remota).

È in grado di instaurare un ponte ssh in modo da sincronizzare anche db dietro firewall.

## jmb-deps

Fa un report delle dipendenze di un pacchetto basandosi su

- l’analisi del log di `buildout -Nv`
- il file setup.py del progetto e di tutte le sottocartele di .src
- il file buildout.cfg
- le informazioni delle eggs dichiarate nelle dipendenze sopra citate

Può essere utile in alcune circostanze, ma sicuramente fallisce in altre.

## jmb-update

Command to help updateinga project. It saves the current status of all repositories, clones in /tmp the project to test if everithing compiles correctly.

## wsgi

djangorecipe crea una configurazione di wsgi che è incompatibile con il virtualenv. La versione modificata da me (sandro) mette la versione corretta.

La motivazione è che il modulo indicato nella configurazione di apache, viene importato da una istanza di python che non è isolata, mentre il meccanismo necessario per rendere disponibili i pacchetti del porgetto (le eggs) e basato sull’uso dei file `.pth` che risiedono solo in alcune cartelle definite in fase di compilazione. È possibile aggiungere altre cartelle con il comando `site.addsitedir()`. La mia versione aggiunge:

    import site
    site.addsitedir(${buildout:directory} + \
                    '/parts/vpython/lib/python2.x/site-packages')

## Creazione link simbolici

Questa sezione è obsoleta. Con `jmb.*` non è più necessaria.

La configurazione di default crea automaticamente una cartella site-packages con i link simbolici agli egg che contengono il pacchetto. Viene creata dalla ricetta links per cui vanno solo messi i nomi dei pacchetti per cui si vuole creare il link, ad esempio:

    [links]
    targets = jumbo-core
              jumbo-timereport

## Documentazione

La documentazione sta in docs. Nella configurazione standard viene automaticamente creata `bin/docs` una script che genera la documentazione e rigenera docs/Makefile in modo che punti ai file corretti con l’ambiente corretto.

Note

al momento viene creata con un nome errato per la variabile `DJANGO_SETTINGS_MODULE`. Per le apps occorre lasciare solo `tsettings`.

Può essere chiamato semplicemente con:

    dj docs

Per le application occorre dichiarare come settings: tsettings nella sezione [django] ed aggiungere:

    absolute_path = True

È possibile fare l’upload in http://docs.thux.it semplicemete aggiungendo l’opzione -u `dj -u docs`

## Test

i test per le application stanno in nome_application/tests/__init__.py e possono essere lanciati con:

    dj t

equivalente a `python manage.py test`.

## Troubleshooting

Esistono alcuni problemi tipici quando si crea un ambiente con buildout. Vediamo di capirli e di capire come risolverli:

### python bootstrap.py

Attualmente questo comando non dà problemi se si usa l’utima versione di bootstrap.py. Alcun progetti/application più vecchi hanno una versione precedente che va aggiornata e che scarica buildout >= 2.0 che non è compatibile con la ricetta tl.buildout_virtual

### bin/buildout -N

Questo può dare molti errori differenti, in generale imputabili ad errori di configurazione dei pacchetti da cui dipende il singolo progetto.

#### jmb.organization-light

    Error: There is a version conflict.
    We already have: jmb.organization-light 0.2.1

Questo è causato dal fatto che abbiamo 2 pacchetti che forniscono il package jmb.organization, uno con nome jmb.organization ed uno con nome `jmb.organization-light`. Il secondo viene trovato per primo e installato e questo confligge con la richiesta di installare `jmb.organization`.

L’unica soluzione funzionante che ho trovato è stato di installare il pacchetto `jmb.organization` come sorgente:

    jmb.organization = hg ${thunder:jmb2}/jmb.organization

#### Error: Bad constraint 0.6.1 django-sekizai>=0.7

Questo errore viene introdotto da django-cms. non essendo io un eperto di django-cms e finchè non ci sarà una spiegazione chiara ho trovato che imponendo `django-cms>=2.3,<2.4` si bypassa il problema

#### Source URL for existing package ‘jmb.organization’ differs. Expected

Errore che capita solo se si usa la versione che scarica i pacchetti sorgente via http, non via ssh. Il motivo sta nel fatto che hg clone nasconde la password nel file `.hg/hgrc` e quando successivamente va a vedere quale URL abbia il repository, non trova corrispondenza.

La soluzione (brutta), è di aggiungere a mano la password nel repository

#### Non installa un pacchetto

Se siete sicuri che il pacchetto sia dichiarato nelle dipendenze, provate a cancellare il file `.installed.cfg` nella cartella del progetto e rilanciate bin/buildout.

### Navigation

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