El Blog de Trespams

Si he fet feina amb Python amb projectes diferents us haureu trobat amb algun d'aquest problemes:

• La llibreria que heu devallat del svn per a un projecte té canvis, les necessitau pel projecte actual però són incompatibles amb el projecte anterior.
• Necessitau provar l'aplicació que teniu amb les mateixes llibreries i versió que hi ha a producció. Podeu tirar de svn per la versió de producció, però les dependències de les llibreries han canviat.
• Teniu tants paquets i llibreries instal·lats al site-packages que les utilitats d'autocompletat es tornen bojes per mostrar-vos les ajudes.

Per a resoldre tots aquets problemes hi d'altres semblants podem fer ús de dues utilitats com són el virtualenv i el virtualenvwrapper, creades per Ian Bicking i Doug Hellmann respectivament. Veurem en aquest article com fer-les servir.

El primer que hem de fer és instal·lar-les. Ho podem fer amb easy_install virtualenv i easy_install virtualenvwrapper. La primera utilitat és la que realment farà la feina, l'altra és un script que ens facilita el maneig i la gestió dels distints entorns.

Suposaré que ens trobam en la situació de que volem crear un entorn net, on crearem la nostra aplicació i que tendrà totes les llibreries i dependències necessàries per a executar-la. Per començar el primer que farem serà configurar el nostre entorn de treball

$mkdir ~/.virtualenvs

Ara editarem el nostre arxibu .basrch i hi afegim

export WORKON_HOME=$HOME/.virtualenvs source /usr/bin/virtualenvwrapper_bashrc

La localització del virtualenvwrapper_bashrc pot canviar segons la distribució, adaptau-la segons convengui.

Després d'editar el .bashrc feim un source ~/.bashrc per a activar els canvis i ja podem crear el nostre primer entorn virtual.

Crearem un entorn anomenat estable que tindrà la versió estable de Django i poca cosa més. Prèviament ens haurem baixat dita versió i l'haurem descomprimida a un directori temporal.

$ mkvirtualenv --no-site-packages estable $ workon estable

Això ens haurà creat un entorn de Python amb les llibreries per defecte. És el que li hem dit amb --no-site-packages. Si no li haguéssim posat aquesta opció, ho hagués creat, però amb tot el que tenim al site-packages actual, si ens interessa bé, però si no, com és el cas, millor pensar en crear els entorns virtuals fent servir aquesta opció.

Ara podem anar al directori on hem descomprimit Django i fer un python setup.py install. Si us hi fixau veureu que Django ara no s'instal·la al directory site-packages del sistema, sinó al del entorn virtuals. Això és així perquè hem activat l'entorn amb la comanda workon. Aquesta comanda ens permet veure els entorns que tenim definits i a més, posant-hi el nom del entorn, canviar d'entorn virtual, a partir del canvi, les comandes d'instal·lació via setup.py o easy_install es faran a l'entorn virtual actiu.

Si voleu tornar a l'entorn de treball del sistema podeu desactivar l'entorn virtual amb un deactivate.

Tenim un petit problema però, necessitam el PIL i és una tudada d'espai tenir-ho que instal·lar des de zero. Per això podem fer dues coses, o bé crear un enllàç simbòlic dins l'entorn virtual, en el nostre cas dins $WORKON_HOME/stable/lib/python2.5/site-packages/ o bé fer ús de la comanda que ens proporciona el virtualenvwrapper anomenada add2virtualenv. Així si executam

$workon estable $add2virtualenv /usr/lib/python2.5/site-packages/PIL

Hauríem afegit al nostre entorn virtual el paquet PIL del sistema. Ho podeu anar fent amb paquets que necessiteu, però teniu en compte que l'objectiu de l'entorn virtual és tenir un sistema net i no acabar amb tots els paquets que hi ha al sistema llincats.

Podem crear tants entorns virtuals com necessitem i vulguem, fins i tot un per cada aplicació. La comanda workon ens permetrà visualitzar-los i canviar entre ells amb tota facilitat.

Si optau per crear un entorn virtual per aplicació segurament trobareu molt útil saber que a directori bin del nostre entorn virtual podem crear dos scripts que d'existir s'executaran associats a l'entorn virtual, es tracta de postactivate que s'executa després d'activar l'entorn i predeactivate que s'executa abans de la desactivació.

En algunes aplicacions el meu postactivate és tan senzill com un canvi de directori cap a la carpeta de feina de l'aplicació i una actualització (via svn up) del codi.

Anem ara al tema de l'autocompletat. Com ja he comentat darrerament estic fent servir Netbeans per Python com a entorn de desenvolupament. Netbeans ens permet definir quins entorns d'execució farem servir (i gràcies a Xus vaig saber del cromo que deia que podíem fer-ho servir per a indicar a Netbeans que fes servir aquest entorn.

Una vegada creat el nou intèrpret de Python dins el Netbeans segurament encara haureu de pensar en fer una cosa més, assignar-ho al nostre projecte ja que en cas contrari tindria l'entorn antic. Així doncs anau a les propietats del projecte i assignau com a Python Platform l'entorn virtual que acabau d'afegir.

Podeu crear tants entorns d'execució de Python com siguin necessaris, cada un amb el seu entorn virtual associat i fer que sigui l'entorn d'execució per defecte del projecte. Això farà que l'autocompletat sols us mostri les opcions que es poden agafar d'aquestes llibreries, resolent un dels emperons més grans que particularment li trobava a l'autocompletat de Netbeans. Amb això i amb la recent descoberta de que depurar Javascript des de Netbeans és possible i més àgil que amb firebug (encara que ho faci servir, deu ser cosa del refresc del navegador), encara fa que em decante més per Netbeans com a entorn de desenvolupament per defecte per Python amb el permís de Vim, clar.

Us aconsello jugar amb els virtualenvs, fer proves, mirar quins paquets i utilitats feis servir més, si els vostres aplicatius s'executen bé en un entorn net (com possiblement serà l'entorn de producció), podeu crear-ne tants com vulgeu. Un entorn típic per a desenvolupar amb Django té un tamany de 35M (du -h $WORKON_HOME/estable/), que no és res pels tamanys dels discs durs actuals.