.. _buildout-utilities: =============== Utilities =============== .. _jmb-start: 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 :file:`setup.py` come scritto sopra piuttosto che nel file :file:`buildout.cfg` così che vengano correttamente ereditate da ogni altro progetto che dichiari questo come dipendenza. Le dipendenze espresse in :file:`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 :file:`.hgignore`, ed un tsettings.py che viene usato come default, sta a voi correggere a mano. .. _dj: 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: py == Lancia l'interprete Python dell'ambiente virtuale. Analogamente a ``dj``, ``py`` chiama bin/py in ogni sotto cartella .. _ipy: 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: jmb-test-setup =============== Questa script permette di mostrare quali versione dei pacchetti sono incluse nell'ambiente virtuale. .. _jmb-prepare: 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: 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: 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: 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 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: 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') .. _link-statici: 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: 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 :ref:`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 :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 :file:`.installed.cfg` nella cartella del progetto e rilanciate :command:`bin/buildout`. .. _ufficiale: http://docs.thux.it .. _djangorecipe: http://pypi.python.org/pypi/djangorecipe/1.3 .. _bootstrap.py: http://downloads.buildout.org/1/bootstrap.py