Programmo in PHP da anni, l’ho seguito, odiato ed amato, con la release 5 sta cominciando a diventare un signor linguaggio, epperò io avevo voglia di espandere un po’ gli orizzonti e così mi sono guardato intorno. Le scelte più gettonate di questi tempi sono:

• Java, l’evergreen che piace a tutti i top manager ma di cui non si trova traccia sugli shared hosting, e poi io non sono un top manager, e quindi a me non ci piace;
• Ruby, il linguaggio bellissimo ma che ancora sugli shared hosting non si vede facilmente [1];
• Python, un altro linguaggio abbastanza bello, che comunque sugli shared hosting… ci siamo capiti.

Se avessi badato all’estetica, avrei scelto Ruby, ma siccome qualche oscuro shared hosting che offre Python c’è, ho scelto Python. C’è sempre l’alternativa server virtuale + smazzamento totalitario. Insomma, comincio a leggere in giro di questo fatto di Python sul web e concludo due cose:

1. Python senza framework è poco più che inutile;
2. Django è un bel framework che va molto.

Accessoriamente ho scoperto che per fare tutte queste cose con Apache (dato che comunque il mio ambiente di sviluppo al momento è il classico LAMP) non si deve usare mod_python bensì mod_wsgi che è un’evoluzione di CGI in salsa curry — più o meno. Installo da Portage www-apache/mod_wsgi e dev-python/django e subito il primo imprevisto: Python non è un preprocessore di pagine HTML, quindi non è che si possono mettere insieme un po’ di script in una directory come si faceva con PHP, bensì bisogna preparare separatamente applicazioni e progetti [2]. Dopo molto cosare di cervello ho capito che non era mica una brutta idea e quindi mi sono messo a seguire questo tutorial introduttivo. Si crea il progetto, si configurano un po’ di cose, e si avvia un server temporaneo che ascolta su http://localhost:8080/ e la cui root corrisponde direttamente al progetto appena creato. Wait, what?! Ma io pensavo di usare il mio bell’Apache e navigare in cose tipo http://localhost/progetto/… così non lo posso fare! Allora mi sono rimboccato le maniche e ho scoperto che si ha da fare quanto segue.

Supponiamo che abbiate creato il vostro progetto in ~/progetti/mysite/. Dentro lì facciamo una directory chiamata per esempio apache/: la facciamo per tenere in ordine le cose, in realtà tutto questo si può fare anche nella directory del progetto. Comunque sia, creiamo un file che si chiama django.wsgi dentro alla directory apache/ che abbiamo appena creato. Il contenuto di questo file ha da essere il seguente:

import os, sys
sys.path.append('/home/utente/progetti')
os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'
 
import django.core.handlers.wsgi
 
_application = django.core.handlers.wsgi.WSGIHandler()
 
def application(environ, start_response):
        # environ['PATH_INFO'] = environ['SCRIPT_NAME'] + environ['PATH_INFO']
        environ['PATH_INFO'] = environ['PATH_INFO']
        return _application(environ, start_response)

La riga commentata è quella che ho trovato nelle guide di integrazione tra mod_wsgi e Django, però ho visto che faceva un bel po’ di casino con gli URL, e quindi l’ho sostituita con quella subito sotto che non mi crea rogne. A questo punto dobbiamo modificare la configurazione di Apache, ma cercheremo di farlo una volta per tutte. Andiamo dentro ad uno dei file di configurazione di Apache, tipo /etc/apache2/httpd.conf e aggiungiamo in fondo le righe

Alias /media/ /usr/lib/python2.6/site-packages/django/contrib/admin/media/
WSGIScriptAliasMatch ^/django/([a-z0-9-_]+) /home/utente/progetti/$1/apache/django.wsgi

La prima riga dipende dalla distribuzione e dalla versione di Python che usate, io uso Gentoo e Python 2.6. La seconda riga funziona così: intanto scordiamoci di fare cose tipo http://localhost/mysite/, almeno in un server di sviluppo. Non ho verificato, ma a senso direi che una direttiva fatta per questo tipo di URL intercetta tutti gli URL che cominciano in quel modo e li redirige al progetto Django col nome indicato, e potete immaginare da voi cosa succede se il progetto non esiste, lasciando stare il fatto che magari quella directory esiste davvero nella DocRoot di Apache e contiene materiale a cui vorremmo accedere. Io, nel mio piccolo, ho scelto di fare in modo che gli URL che rimandano a progetti Django siano formati come http://localhost/django/progetto/ in modo da non far confusione: nella mia DocRoot non c’è alcuna directory /django/ e se scoprissi in seguito che in realtà mi serve averla posso cambiare l’alias e ripristinare la situazione in tempo zero. Se sapete leggere le espressioni regolari avevate già capito tutto e sapete anche come adattare le cose al vostro gusto.

Fatto questo, è ora di tornare al tutorial e proseguire nello studio. C’è solo una cosa che mi disturba molto, cioè dover riavviare Apache ogni tanto perché a quanto pare Django (ma non sono sicuro che sia un limite solo di Django) non è in grado di accorgersi se alcuni file sono stati modificati e comportarsi di conseguenza [3]. So che esistono modi tipo tenere sotto controllo di file con inotify e far riavviare Apache al bisogno, ma non mi sembra comunque una soluzione fattibile, anche perché, non ho capito come e perché, ma da quando ho installato WSGI e tutto quanto, Apache mi impiega un paio di ere geologiche a riavviarsi.

Il vantaggio di seguire le mie istruzioni è che forse abbiamo una chance di capire come mettere su un server di produzione con mod_wsgi, in cui normalmente non è che siamo sempre lì a modificare l’applicazione e riavviare Apache; il vantaggio di non seguirle è che il serverino scrauso che il tutorial dice di avviare ad un certo punto riesce a gestire automaticamente un certo numero di cambiamenti nei file, mentre per altri è comunque necessario riavviarlo. Insomma, vedete voi.

1. Comunque consiglio di studiarselo, ché è un bel linguaggio, e la Why’s (Poignant) Guide to Ruby è un gran bel modo per farlo.[↑]
2. Se vogliamo, intendiamo progetto come sinonimo di sito, in cui si mettono i file di configurazione che includono le varie applicazioni.[↑]
3. Pare che abbia da ricostruire file, modificare database, insomma: un po’ di roba dietro le quinte che per uno abituato ai linguaggi col compilatore non suona tanto strano, epperò Python non è un linguaggio compilato.[↑]