Utilities

Tutte le utility che presento qui hanno un’opzione -h per l’help. Non mi soffermo molto sulle cose utili a me che curo il deploy, ma solo a quello che serve agli sviluppatori… tanto non leggete neanche quando ve lo chiedo esplicitamente (questo è uno sporco trucco per capire se leggete…, non cascateci)

jmb kick

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 kick  cms -vbm nome-progetto

o alternativamente per una app:

jmb kick  japp jmb.miapp

es:

jmb kick  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]:

[versions]
Django == 1.11.11

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 migrate --all
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 tunnel ssh in modo da sincronizzare anche db dietro firewall.

Potete generare una configurazione funzionante semplicemente con:

jmb-syn -c

è possibile committare la configurazione .sync in mercurial e creare invece una configurazione minimalista .sync.local che contenga ad esempio:

LOCAL_CLUSTER=10/main
LOCAL_DB_NAME=db_name
LOCAL_DB_USER=

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:

todo, la sezione precedente riporta problemi risolti…