Bitácora de Vuelo

¿Dónde van las cosas?

Volviendo a el lugar en dónde se instala el código Python... si uno quiere distribuir una biblioteca, la respuesta es sencilla: en el directorio de bibliotecas de Python de tu sistema. ¿En dónde particularmente? Bueno, depende de tu sistema; incluso en Linux esto fue cambiando y no es el mismo lugar siempre. En mi máquina tengo /usr/lib/python2.6/dist-packages/, que en parte apunta a /usr/share/pyshared/.

Igual, no importa la ubicación exacta: usando distutils (u otras alternativas) las bibliotecas van a parar al lugar correcto sin mayor esfuerzo.

¿Pero qué pasa si no es una biblioteca sino un programa? El primer detalle es que necesitamos un ejecutable que arranque nuestro programa. Distutils y amigos tienen esto bastante bien manejado, se les puede especificar un script, y terminan instalando todo de la siguiente manera:

script -> /usr/bin/</span>
todo el resto /usr/lib/python2.6/dist-packages/ (o similar)

Hasta acá todo bien, ¿no? No. Resulta que nuestro programa tiene imágenes, archivos de audio, etc, y está "mal visto" meter esos archivos "de datos" dentro del directorio de bibliotecas de Python. Entonces, lo que recomiendan por ahí es:

script -> /usr/bin/
archivos de datos -> /usr/share/
código python -> /usr/lib/python2.6/dist-packages/ (o similar)

Esto ya no es tan fácil de lograr, porque la distribución de archivos de datos es como un parche en los sistemas de distribución de bibliotecas.

Además, si nos vamos a poner quisquillosos de no meter archivos de datos en el directorio de bibliotecas, yo pregunto: ¿por qué meter código de nuestro programa, que no es una biblioteca, en el directorio de bibliotecas?

Entonces me embarqué en el siguiente capricho: quería que la distribución de mi programa vaya a parar a:

script -> /usr/bin/ todo el resto -> /usr/share/

Los archivos de datos, por supuesto, mezclados con "todo el resto".

Estructura de nuestro programa

Primero lo primero, ¿cómo organizamos nuestro proyecto? Yo tengo lo siguiente (simplificado, pueden ver toda la estructura en los archivos del proyecto Encuentro):

• un directorio 'bin' donde tengo el script que arranca todo:

  bin/encuentro

esto es un archivo ejecutable que no hace mucho más que jugar un poco con los directorios y el sys.path para que se encuentre al resto del código Python de nuestro programa (en dos situaciones: cuando ejecutamos bin/encuentro desde el repositorio mientras estamos desarrollando, y cuando está instalado finalmente en el sistema), e inicializar alguna estructura básica y arrancarla, para que comience nuestro programa.

• un directorio con el nombre de nuestro proyecto, con el resto del programa:

  encuentro/__init__.py
  encuentro/main.py
  encuentro/network.py

• directorios con los archivos de datos, adentro de nuestro proyecto (no por separado), en este caso:

  encuentro/ui/main.glade
  encuentro/ui/preferences.glade
  encuentro/ui/update.glade

Una vez aclarado eso, quedan dos preguntas sencillas y una complicada por contestar: las sencillas son ¿cómo el script encuentra al resto del programa instalado? y ¿cómo accedemos a los archivos de datos desde nuestro código?.

La primera es usando una variable que se inyecta en el script en el momento de instalar el programa (ver más abajo el cuándo hacemos eso en setup.py).

La segunda es accediendo a los archivos de forma relativa al código. Yo tengo esto al principio del programa:

BASEDIR = os.path.dirname(__file__)

y luego hago cosas como:

data_file = os.path.join(BASEDIR, 'ui', 'preferences.glade')

Finalmente, la pregunta complicada: ¿cómo hacemos para que todo esto funcione?

Distribuyendo programas

En realidad, la respuesta no es tan complicada una vez que está resuelto (como tantas cosas en la vida).

Para incluir todos los archivos, en el setup.py, en la llamada a setup() hay que poner:

packages = ["encuentro"],
package_data = {"encuentro": ["ui/*.glade"]},
scripts = ["bin/encuentro"],

Fíjense como ahí declaro el paquete donde está mi programa, el script, y los archivos de datos. Pero hay un bug, hasta en Python 2.6 inclusive, que hace que para meter los archivos de datos con eso sólo no alcanza, y hay que declararlos también en el MANIFEST.in:

include encuentro/ui/*.glade

Para que todos estos archivos vayan a parar al lugar correcto, hay que hacer algo específico: una clase que acomoda cosas en el proceso de instalación. Pueden ver el detalle de esa clase en el setup.py de Encuentro, pero basicamente hace dos cosas:

• Construye un directorio donde va a quedar todo con el prefijo indicado, "share" y el nombre del proyecto, y autocorrije el directorio de instalación con eso.

• Guarda ese directorio de instalación nuevo en los scripts declarados, usando una cadena especial como bandera, de manera que al quedar el script instalado sabe dónde buscar el programa entero.

(importante: no olvidar declarar en la llamada a setup() a esta nueva clase como la clase que será usada para instalar!)

Finalmente, está bueno probar que todo funca bien. Las pruebas que yo hice fue crear el .tar.gz con python setup.py sdist, descomprimirlo en otro lado que nada que ver y hacer python setup.py install --prefix=/tmp (para que se instale en /tmp y probarlo ahí adentro) y también sudo python setup.py install (para que se instale en el sistema y probarlo así).

También, luego de hacer todo el proceso de packaging, cuando pbuilder me dejó el .deb, lo descomprimo y veo que la estructura está correcta y que la variable reemplazada en el script tiene el valor que debería; igual, la prueba de fuego con el .deb es instalarlo con dpkg -i y probar el programa.

Nota final: ahora me falta armar un .exe para que se pueda ejecutar en Windows, pero eso será otro post.