Encuentro 0.4, con todo

Python — Miércoles 04 de Enero de 2012, 23:27


Encuentro es un simple programa que permite buscar, descargar y ver contenido del Canal Encuentro.

Notar que este programa no distribuye contenido de Canal Encuentro, sino que permite un mejor uso personal de esos contenidos. Por favor, referirse al sitio web de Canal Encuentro para saber qué se puede y qué no se puede hacer con los contenidos de ese sitio.

Encuentro

¡Con esta versión entramos en "alfa"! O sea: están todas las funcionalidades que pretendo, veremos si aparecen bugs para corregir...

La versión 0.4 trae los siguientes cambios con respecto a la versión anterior:

- Ahora se puede filtrar todos los programas para encontrarlos más fácil.

- ¡Tenemos una versión para Windows! (gracias Javier Andalia)

- ¡Tenemos un instalador para Arch Linux! (gracias Diego Mascialino)

- Mostramos versiones de todas las bibliotecas usadas al arrancar.

- Mejor info de error si no se encuentra alguna biblioteca.

- Correcciones pequeñas, y más control de errores...

Para las distintas formas de instalarlo en Debian/Ubuntu, suscribirse al PPA, cómo hacer con Arch Linux, bajarse el instalador para Windows, o dónde encontrar el tarball genérico, vayan a la página del proyecto.

Recuerden revisar el archivo AYUDA.txt si tienen alguna duda de cómo usar el programa.

¡Que lo disfruten!


La CDPedia en Educ.ar

Python — Martes 20 de Diciembre de 2011, 17:35


¡Finalmente! Luego de varios meses de discutir, pelear diseños, frases que debían aparecer en las cajas y en lo impreso del CD, y varios etcéteras más, aparecieron las cajas de Educ.ar.

Todavía no me queda claro si ya se enviaron y llegaron a las escuelas de todo el país, ya se enviaron y van a ir llegando en las sucesivas semanas, o se va a mandar a principios del año que viene... pero bueno, a nosotros ya nos dieron unos ejemplos del producto final.

La CDPedia en Educ.ar

Como ven en la foto, tenemos un pack para nivel medio y otro para nivel superior. En ambos casos se incluye un CD que es "la wikipedia en el aula". Aunque la caja y los discos tienen mucho de lo que les obligamos a poner (las licencias correspondientes, o la leyenda "se permite la copia y distribución de este disco" bien legible, por ejemplo), ni esa caja ni el disco tienen los logos de PyAr ni de Wikipedia. Una lástima.

Por otro lado, también hicieron cajitas separadas con la "wikipedia en el aula", y para esos sí: está el logo de PyAr en el reverso, y el disco, y la URL de la CDPedia en el frente, bien grande.

No está mal, en general, pero jode porque ellos NO cumplieron con lo prometido, :(

En fin, de a poquito.


Diversidad cultural

Python — Miércoles 12 de Octubre de 2011, 17:41


Hoy, 12 de Octubre, fue durante casi todo el siglo pasado y parte de este el Día de la Raza, pero fue cambiado hace poco y ahora se denomina Día del Respeto a la Diversidad Cultural.

Como festejo de este día, les dejo la traducción de la declaración de diversidad de la Python Software Foundation (pueden ver el original acá), declaración que Steve Holden comentó y explicó en la última PyCon en Argentina, y la cual comparto:

La Python Software Foundation y la comunidad global de Python damos la bienvenida y alentamos la participación de todos. Nuestra comunidad está basada en el respeto mutuo, la tolerancia, y el ánimo, y estamos trabajando para ayudarnos entre todos a vivir en base a estos principios. Queremos que nuestra comunidad sea más diversa: dondequiera que estés, y cualquiera sea tu origen, te damos la bienvenida.


PyCon Argentina 2011, Junín

Python — Miércoles 28 de Septiembre de 2011, 19:57


Y pasó la tercer Conferencia Nacional de Python Argentina. Este año se hizo en Junín.

Junín no es al lado de casa pero tampoco es demasiado lejos... salimos con Lucio, Ricardo y Tatiana (disertante, que se vino desde Brasil) un rato antes de las seis de la tarde del jueves (más que nada para no agarrar el tráfico de toda la gente saliendo de trabajar), y a las diez de la noche ya estábamos cenando allá.

La conferencia propiamente dicha arrancó el viernes a la mañana; luego de una registración un poco complicada arrancó una keynote a la que asistí, estuve haciendo sociales un rato por los pasillos, y cerramos la mañana con un panel de programadores que trabajamos en Canonical, moderado por Nico César, con preguntas del público sobre qué hacíamos, cómo lo hacíamos, etc.

Almorzamos en un lugar cercano, algo liviano, y estuve un rato en otra plenaria que no me interesaba demasiado, luego un rato afuera charlando, y justo antes del break de la tarde di mi clásica "Entendiendo Unicode"... es que el público se renueva, ¿viste?

Después del break, Lightning Talks! Siempre están buenas! Gracias a Manu Quiñones me enteré de la existencia de MyPaint, que está buenísimo, y yo por mi parte mostré un truquito interesante para hacer ejecutables Python, que ya mostré acá. Para cerrar el primer día de conferencia, hubo una plenaria sobre PyPy que estuvo buena, por Maciej Fijalkowski.

Ni bien terminó todo, Nico César me pidió la revancha de unos partidos de pool que le había ganado el año pasado, y salimos corriendo a jugarnos unas fichas... pero estaba cerrado! Abría recién a las ocho y media, pero a esa hora ya íbamos a estar cenando, así que apuntamos directamente a donde nos íbamos a encontrar con la gente a comer.

Como Alecu había avisado a todos que nos encontrábamos ahí, invadimos el bar, ¡éramos 66 comensales de la conferencia! Las cervezas y las pizzas corrían con un ritmo vertiginoso, y todos la pasamos muy bien. El lugar, super recomendable: Tío Lucas (fue barato, nos atendieron bien, y aunque había tanta gente se podía charlar bien, no era todo un gran barullo).

Cena en Tio Lucas

Ni bien terminamos de pagar, nos escapamos con Perrito y Nico al pool antedicho, y jugamos unas fichas, tomamos unas cervezas, llegó más gente... parranda, bah. Lo bueno es que como cenamos temprano, terminamos también acostándonos temprano (o al menos no demasiado tarde), lo que estuvo muy bien porque nos quedaba la mitad de conferencia por delante.

Al otro día, dí mi segunda y última charla en el primer slot, "Python más rápido que C" (versión actualizada, con comparaciones con PyPy). Luego estuve un rato charlando con Lucio y Guillo sobre unos temas de laburo, y enseguida me metí en una charla de Ricardo Kirkner sobre fabric. Para cerrar la mañana, una buena plenaria de Ricardo Quesada sobre "Vivencias desarrollando un proyecto open source".

Riq en su plenaria

Ni bien terminó la charla nos fuimos todos corriendo a una plaza en la esquina de la universidad a sacarnos una foto grupal, y luego a almorzar... donde nos demoramos apena más de lo que debíamos y terminamos llegando a la plenaria de Wesley Chun (sobre Python 3) un poco tarde.

Lo mejor de la tarde fueron una charla sobre Python en Android por Tatiana Al-Chueyr, otra tanda de Lightning Talks, y la última plenaria: el chairman de la Python Software Foundation, Steve Holden, hablándonos de la PSF, historia, comunidad, e incluso diversidad dentro de la misma.

Y el cierre! Unas palabras de los organizadores, regalos para los asistentes, para los disertantes, y todos para casa. Bueno, no para casa... había una cena para disertantes, y luego nos fuimos nuevamente a jugar unos pools al bar de enfrente del hotel.

Ese bar está buenísimo: tiene música pero no demasiado alta, buenas mesas de pool, un ambiente copado... si tuviera uno así por acá jugaría mucho más seguido al pool :) Ahora que lo pienso, debería revisar un par de bares que ví por la zona donde vivo, que parece que son más chetos, pero habría que confirmarlo, a ver si alguno tiene un pool piola.

Anyway, luego del pool, ya siendo como las dos de la mañana, cruzamos la calle y nos fuimos a dormir. Y al otro día nos levantamos, desayunamos, al rato partimos, viajamos tranqui, llegamos a la tardecita... todo bien.

Foto grupal
(hagan click en la foto para verla grande)

En fin. Muy buena conferencia, con buena asistencia, buenas charlas, y bien organizada. Un lujo tener estos eventos en Argentina, al alcance de todos.


Encapsulando Python en un binario

Python — Sábado 24 de Septiembre de 2011, 17:00


Este es un lindo truquito que no es de mi autoría, sino que es de John Lenton (él lo mostró en una reunión del laburo), pero como yo ya lo mostré en PyCon Brasil el año pasado, y en PyCon Argentina ayer, lo pongo acá para el que lo quiera mirar...

Arrancamos con nuestro programa o proyecto Python que queremos meter adentro del binario... para nuestro ejemplo acá, crearemos un directorio, lo hacemos paquete de Python, y adentro creamos lo que sería el programa principal de nuestro sistema, con una función adentro que es la que arrancaría todo...

facundo@exopus:~/prueba$ mkdir proyecto
facundo@exopus:~/prueba$ cd proyecto/
facundo@exopus:~/prueba/proyecto$ touch __init__.py
facundo@exopus:~/prueba/proyecto$ cat principal.py
def run():
    print "Arrancamos!"
facundo@exopus:~/prueba/proyecto$ cd ..
facundo@exopus:~/prueba$

Tenemos que probar que podamos arrancar nuestro sistema desde el directorio padre... a veces no es tan fácil, hay que jugar un poquito con los paths de dónde importamos cosas, pero en este ejemplo es sencillo. Pero podemos probarlo facilmente:

facundo@exopus:~/prueba$ python
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24)
...
>>> import proyecto.principal
>>> proyecto.principal.run()
Arrancamos!
>>>

Una vez que lo logremos ejecutar así, tenemos que  poner ese mismo código en un archivo con nombre __main__.py en el directorio padre de nuestro proyecto:

facundo@exopus:~/prueba$ cat __main__.py
import proyecto.principal
proyecto.principal.run()

Volvemos a probar que nuestro sistema funciona correctamente:

facundo@exopus:~/prueba$ python __main__.py
Arrancamos!

El próximo paso es meter todo adentro de un archivo ZIP, aprovechando que Python es capaz de interpretar directamente este tipo de archivos comprimidos (por eso el nombre especial de antes, para que Python lo reconozca):

facundo@exopus:~/prueba$ zip -r proyecto.zip __main__.py proyecto/
  adding: __main__.py (deflated 27%)
  adding: proyecto/ (stored 0%)
  adding: proyecto/__init__.py (stored 0%)
  adding: proyecto/principal.pyc (deflated 45%)
  adding: proyecto/__init__.pyc (deflated 30%)
  adding: proyecto/principal.py (stored 0%)

Probamos nuevamente que, hasta acá, funcione todo correctamente:

facundo@exopus:~/prueba$ python proyecto.zip
Arrancamos!

Finalmente, metemos todo eso adentro de un binario, indicando que se va a interpretar con Python, y haciéndolo ejecutable:

facundo@exopus:~/prueba$ ( echo '#!/usr/bin/env python'; cat proyecto.zip ) > miproyecto
facundo@exopus:~/prueba$ chmod +x miproyecto

¡Ya está! Ahora podemos ejecutar ese binario, como cualquier otro binario, y realmente estaremos ejecutando nuestro proyecto Python:

facundo@exopus:~/prueba$ ./miproyecto
Arrancamos!

Genial, :)


Empaquetando un programa hecho en Python

Python — Lunes 05 de Septiembre de 2011, 17:17


Estos son los pasos genéricos para, desde un proyecto que tiene el setup.py funcionando (ver este post para ayuda con eso), armar un paquete .deb y publicarlo en un PPA. El .deb es un archivo instalable en Debian o Ubuntu, y el PPA es una forma de registrarse para que el programa se actualice automáticamente cuando hay nuevas versiones (obvio, preguntándole al usuario, como el resto del sistema).

Traté de ser conciso para que no se pierdan los pasos en un mar de palabras, pero explicar alguito de cada punto, y dar alguna referencia para seguir investigando. Esta guía está casi copiada de una menos genérica y en inglés que había preparado Naty Bidart en el laburo... la idea es que quede aquí en castellano y más explicada...

Quizás necesiten instalar algunas dependencias (por ejemplo: bzr, bzrtools, bzr-builddeb, ubuntu-dev-tools, libcrypt-ssleay-perl), y configurar algunas cosas:

- En el archivo .bashrc configurar nombre y mail para lo que son los .deb:

    export DEBFULLNAME="Nombre Completo"
    export DEBEMAIL="[email protected]"

- Crear en el home un archivo .devscripts con este contenido:

    DEBUILD_DPKG_BUILDPACKAGE_OPTS='-i -I'

- Tener un entorno pbuilder configurado /para cada distro/ a la que quieran apuntar (en este ejemplo, usé 'maverick', reemplacen apropiadamente):
     - crear un symlink en algún lado de vuestro PATH llamado pbuilder-maverick, apuntando a /usr/bin/pbuilder-dist
     - en algún lado dentro del home (por ejemplo, en un directorio “~/pbuilder”), ejecuten: pbuilder-maverick create
     - regularmente (o antes de armar un paquete), actualicen el entorno de pbuilder con: pbuilder-maverick update

Por último: sí, estos pasos están fuertemente orientados a usar bazaar en todo el proceso. Es lo que hay :)

Presten atención a los comandos que ejecutan, especialmente a los cambios de "." y "-" por "_", y a todo lo que use 'tuproyecto'. Cualquier duda, pregunten.

- Arrancamos trabajando con trunk.

- Revisar que el setup.py funcione correctamente (que arme, instalarlo, y generar un tarball). Luego de instalarlo en /tmp/test ir allí y ver que funcione correctamente. Luego de generar el tarball, ir a otro directorio que no tenga nada que ver, desarmarlo y ver qué esté todo bien.

    ./setup.py clean build
    ./setup.py clean install --prefix=/tmp/test
    ./setup.py clean sdist

- Cambiar la versión en setup.py a la nueva (en este ejemplo, sería X.Y.Z). Marcar a nivel bazaar un nuevo release:

    bzr commit -m "[release] vX.Y.Z"
    bzr tag release_X_Y_Z
    bzr push

- Hacer un "bzr log" y preparar el changelog y las release notes. El changelog es una lista exhaustiva de todos los cambios, y las release notes es un subconjunto de eso, normalmente lo que es más relevante, interesante, o útil a la persona que quiere saber qué tenemos de nuevo en esta versión de nuestro programa.

- Generar y subir el tarball a Launchpad. El último paso setea EDITOR porque lp-project-upload va a abrir dos archivos para que escribamos el changelog y las release notes que preparamos antes (pueden usar el editor que más les guste).

    ./setup.py clean sdist
    cd dist
    EDITOR=vim lp-project-upload tuproyecto X.Y.Z tuproyecto-X.Y.Z.tar.gz

- Copiar el tarball (con un nuevo nombre) y preparar un nuevo branch para empezar a empaquetar:

    cp dist/tuproyecto-X.Y.Z.tar.gz ../tuproyecto_X.Y.Z.orig.tar.gz
    cd ..
    bzr branch trunk/ tuproyecto-X.Y.Z
    cd tuproyecto-X.Y.Z/
    bzr dh-make --bzr-only tuproyecto X.Y.Z ../tuproyecto_X.Y.Z.orig.tar.gz
    python-mkdebian

- Editar el changelog con: EDITOR=vim dch (yo tiendo a poner las release notes aquí)
    - Agregar lineas de changelog
    - Agregar un -0ubuntu1 al nro de versión entre paréntesis

- Archivos necesarios para Debian (tocar como dice acá o traer intactos de otro packaging que se haya hecho antes):
    - agregar un directorio source adentro del dir debian, y poner en ese nuevo directorio un archivo format con el siguiente contenido:
        3.0 (quilt)\n
    - confirmar que las dependencias sean las correctas en el archivo debian/control
    - modificar debian/copyright como corresponda
    - crear un archivo debian/watch con el siguiente contenido:
        version=3
        http://launchpad.net/tuproyecto/+download .*/tuproyecto-([\d.]+)\.tar\.gz

- Armar el paquete en si, y luego del tercer paso probar el .deb que quedó en ~/pbuilder/maverick_result (o en el directorio donde hayan puesto pbuilder ustedes):

    debuild -S -sa
    bzr add debian
    pbuilder-maverick build ../tuproyecto_X.Y.Z-0ubuntu1.dsc

- Actualizar el PPA (se puede crear el PPA desde tu página personal de Launchpad):

    dput ppa:<nombre_de_ppa_que_corresponda> tuproyecto_X.Y.Z-0ubuntu1_source.changes

- Luego de unos minutos, debería aparecer acá:

    https://launchpad.net/~tunombre/+archive/tuproyecto/

- Esperar que se buildee la versión que subieron (puede tardar algunas horas, un par de días, normalmente no más), y luego si quieren publicar lo mismo para otras versiones de Ubuntu sólo alcanza con copiar los fuentes a la versión que corresponda, desde la siguiente página:

    https://launchpad.net/~tunombre/+archive/tuproyecto/+copy-packages


CDPedia, un poco de historia

Python — Sábado 27 de Agosto de 2011, 09:11


Con motivo de la reciente liberación de la versión 0.7 y algo más, me puse a pensar un poco sobre la historia de la  CDPedia.

Cuenta la leyenda (?) que todo arrancó en el sprint posterior al primer PyDay de Santa Fé; la idea la trajo el omnipresente Leito Monk, pero parece que había surgido del Gran Nico César. No sé, ustedes vieron como son los mitos.

Sprinteando en un bar

(éramos tan jovenes...)

La cuestión es que ahí se arrancó el proyecto. Creo que estuvo en un par de SVNs por ahí (o algún CVS?) hasta que terminó en donde está ahora hosteado el proyecto. Las mejoras en el proyecto fueron muy por ráfagas. Recuerdo que siempre se trabajó mucho en este proyecto durante los PyCamps (los dos en Los Cocos, el de Verónica, y el de La Falda), donde muchas personas le dedicaron un buen tiempo, pero también se realizó bastante durante otras reuniones.

Recuerdo, a modo de ejemplo, dos sprints: uno fue en un incipiente hacklab, donde (principalmente) Lucio y Nubis experimentaron sobre el índice para las búsquedas, y también durante la fundación de Wikimedia Argentina, donde presentamos por primera vez el proyecto y trabajamos en la primera parte del procesamiento de datos.

Una gran característica de la CDPedia, indiscutiblemente el proyecto más grande y más largo de Python Argentina, es que siempre se mantuvo orientado al mismo objetivo: tener una wikipedia offline con fines sociales (distribuir en escuelas sin conexión a internet, que el conocimiento sea libre, etcétera), pero sin dejar de que sea divertido (es decir, hacerlo en Python), y manteniendo libre el proyecto (no sólo el producto final, que recomendamos copiarlo y repartirlo, sino el código en sí).

Hasta el 2009, los avances fueron como conté, esporádicos. Pero resulta que Martín Varsavsky se casó, y Jimmy Wales le regaló para el casamiento la posibilidad de que se distribuya una wikipedia offline en Argentina. Preguntó cuales habían, la CDPedia era la que se mejor ajustaba a lo que se necesitaba, y vino Jimmy a Buenos Aires, le mostramos la CDPedia, y luego hubo una reunión en Educ.ar para terminar de acordar esto (fueron Jimmy por Wikimedia, Enrique Chaparro por Wikimedia Argentina y Alecu por PyAr).

Trabajando en el PyCamp

(hagan click en la imagen para ver la foto original, si están curiosos con lo que dice el pizarrón)

En parte porque Educ.ar quería meter la CDPedia en un disco de ellos (con carátula de ellos, algunas otras páginas, etc), y en parte porque nosotros vimos la oportunidad, logramos que dos chicos de PyAr, Diego Mascialino y Hernán Olivera, sean becados para trabajar part time en esto.

Así que agarraron la versión 0.6 que recién había salido (con Alecu nos habíamos apurado a cerrar muchos detalles para tener algo presentable y funcionando a Jimmy Wales), y le entraron a darle. Esto le dio bastante impulso al desarrollo del proyecto, sumado a que yo también por esa época tomé el compromiso interno de trabajar regularmente en esto, y a que luego de que se terminara la beca Diego siguió trabajando en el proyecto, y que se sumó como "laburante regular" Santiago Piccinini.

Con todo este trabajo, y un nuevo "empujón" en el PyCamp del 2011, pudimos terminar de cerrar la versión 0.7, que entregamos a Educ.ar y debería estar distribuyendo por estas semanas a todas las escuelas del pais.

Para minimizar la injusticia de haber nombrado solamente a algunas personas en el texto anterior, para que se den una idea de la magnitud del proyecto (y a riesgo de aburrirlos), les dejo la lista del resto de personas que trabajaron de una u otra forma en el proyecto: Agustín Henze, Antonio Lenton, Alejandro David Weil, Claudio D. Freire, Ezequiel Diaz Marquez, Felipe Lerena, Gonzalo Delgado, Gonzalo García, Guillermo Gonzalez, Hugo Ruscitti, Lucio Torre, Marcos Dione, Martín Gaitán, Maximiliano David Bustos, Nicolás Miyasato, Pablo Ziliani, Piukeyen Tappa, Ricardo Kirkner, Sebastian Farioli, y Zuzel Vera Pacheco

Para terminar, les cuento que puse una versión menos personalizada de este texto en el wiki de PyAr, para que aquellos que recuerden más y más detalles los agreguen ahí.


Distribuyendo un programa hecho en Python

Python — Miércoles 22 de Junio de 2011, 17:56


Más que un análisis completo de las tecnologías para permitir la distribución de programas hechos en Python, este post es casi una receta o colección de anotaciones para seguir un camino. Y es que es un camino que no me fué fácil recorrer, porque la mayoría de los mecanismos para distribuir código Python están pensadas para distribuir bibliotecas hechas en este lenguaje, y no programas.

¿Dónde está la diferencia? En dónde van las cosas.

Antes de seguir: para todo el armado usé distutils, que es lo que está en la biblioteca estándar. Le pegué una mirada a otras cosas como setuptools, distribute, etc, pero todas (aunque son más aptas para cosas más complejas) no me solucionaban el problema básico y me complicaban un poco la vida en otros aspectos.


¿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/
  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.


Enjuewemela 0.3 está en la calle

Python — Sábado 21 de Mayo de 2011, 16:56


Enjuewemela es aún otro juego similar a los populares "Bejeweled" o "Diamond Mine". El juego se basa en alinear 3 o más gemas, tanto verticalmente como horizontalmente, intercambiando gemas adyacentes. Está (por supuesto) escrito en Python, usando el framework para juegos cocos2d.

La versión 0.3 trae un montón de nuevas características, y muchos bugs corregidos. Lo pueden descargar de acá.

Noten sin embargo que todavía es una liberación pre-alfa: tiene un montón de detalles a mejorar, y necesita mucho amor a nivel de "arte".

Algunos de los cambios más grandes son:

- Modos de juego Clásico y Apurate! Prueben ambos, se van a divertir, :)

- Las gemas explosivas y mágicas están completamente implementadas.

- Completo soporte para internacionalización.

- El puntaje se graba por tipo de juego, y hay una pantalla de Puntajes Máximos.

- No más límite para los niveles de juegos.

- Las piezas son seleccionables, o se pueden mover arrastrándolas.

- Los puntajes se indican como burbujas al lado de la gema seleccionada.

- El flujo general del juego está terminado, incluyendo el menú completo de "opciones" y una pantalla de "créditos".

- Ahora se puede salir con ESC, y pausar el juego con "p" o la tecla de pausa.

Para más información, pueden visitar la página del proyecto.


PyDay en Córdoba

Python — Martes 03 de Mayo de 2011, 17:01


El sábado pasado se hizo un nuevo PyDay en Córdoba. Algunas fotos acá.

Salí en avión el viernes a la tarde, en un vuelo que tuvo demora pero que me dejó en Córdoba a las seis y monedas. Me tomé un bondi, pasé un rato por lo de Naty y Matías, y me fui a cenar con Roberto Allende y Daniel Valfre, volví y a la cama

El sábado nos levantamos tempranito y fuimos hasta la UTN con Matías (Naty venía más tarde). Llegamos, nos registramos, y empezamos a reencontrarnos con tanta gente que uno se reencuentra en estos eventos.

Las charlas del PyDay estaban separadas en dos tracks, principiante y avanzado. Así que al rato me metí en la sala donde eran las avanzadas y me quedé ahí hasta el mediodía.

Instrucciones y programa

Algunas charlas que me interesaron: sobre NLTK y procesamiento de lenguaje natural, por Pablo Duboue y Rafael Carrascosa, realmente muy interesante todo lo que se puede hacer; una sobre Python, Sugar y robótica, por Valentín Basel, muy groso controlar un robot físico con lo que es la evolución del Logo; una sobre MyHDL por Martín Gaitán, donde vimos como diseñar silicio usando Python; y una sobre DBus por Alecu, un tema que más o menos ya sabía pero siempre se aprende algún detalle.

Luego vinieron las lightning talks, mi plenaria sobre "Comunidad, anarquía y subversión", y el cierre. Estuvo muy bien el evento.

Al toque salimos varios caminando hacia Nueva Córdoba, una zona a unas quince cuadras de la Universidad donde podíamos encontrar algún lugar para tomar algo. Algunos sólo tomamos una cerveza, porque después volvíamos a la cena armada para los disertantes y organizadores, pero otros se quedaron a comer ahí, especialmente porque volvían esa misma noche a sus hogares y no les daba el tiempo.

Así que sólo cuatro nos volvimos de ahí para la Universidad (esta vez nos tomamos un taxi porque estaba mucho más frío el asunto, y el camino era largo y duro (?)), y fuimos los primeros en llegar al lugar. Aprovechamos y arrancamos con unos metegoles, y ahí fue cayendo la gente.

Mucha charla, partidos de ping-pong (hay que banear a Matías Herranz de cualquier torneo de ping-pong: nos pasó el trapo a todos), cerveza y choripán, más charla, etc... una cena muy copada.

La gente se fue retirando, y los más jóvenes (?) decidimos que la joda siguiera... bah, Perrito me dijo "vamos a tomar un café" y ahí arrancamos para otro lado. Terminamos yendo Perrito, Nueces, Anggie, su novio Catriel, y el que suscribe a un lugar a tomar un trago. Y más y más charla, hasta que el frío y el día largo hicieron estragos suficientes, y emprendimos la retirada (Perrito me hizo la gauchada de llevarme hasta lo de Naty).

Al otro día, me levanté tempranito, me pegué un baño y preparé todo, desayuné con Naty, y de ahí al aeropuerto, y a casita, con la familia.


Adopte un newbie

Python — Miércoles 06 de Abril de 2011, 12:45


En el último PyCamp Pablo Mouzo tiró la maravillosa idea de que aquellos con mucha experiencia dando charlas podíamos ser mentores de gente que se iniciaba por ese camino, para dar consejos, transmitir experiencia, etc. Yo me propuse como mentor para aquel que quisiera proponer una charla en cualquiera de los eventos de PyAr.

Pero a ese concepto Mariano Guerra se le dió otra vuelta de rosca, y armó una página en la que personas con buena experiencia en PyAr o Python se proponen como mentores, los newbies se proponen como mentados, en función de los perfiles de los tutores, y luego los mentores aceptan dedicar una cantidad de tiempo semanal a las consultas del mentado (por mail, IM, en persona o lo que se decida), el mentado acepta documentar sus pasos de aprendizaje en un blog y a dar una charla en el evento en el que se considere que entraron en la "adultez pythonistica".

Mentor

Ahí es donde me puse a pensar que en mi (poco) tiempo libre empujo (o trato de empujar) algunos proyectos que son bastantes variados entre sí, y que pueden ofrecer una buena oportunidad para que alguien arranque y se ponga a aprender, no tanto Python, sino como trabajar en un proyecto.

Como verán abajo, hay uno que está en castellano y el resto en inglés. Uno hosteeado en Google Code, uno en Trac, el resto en Launchpad. Algunos con lista propia, otros no. Algunos con más tests, otros con menos. Diverso.

Y creo que los proyectos son lo suficientemente variados como para que sea más fácil elegir :).

- CDPedia: Es un proyecto de Python Argentina para tener la información de la Wikipedia en castellano accesible aunque no tengas una conexión a Internet.

- Lalita: Yet another IRC bot, one where new functionality is simple to create by just adding easy-to-write plugins.

- Enjuewemela: Crazy game with a lot of gems that tend to disappear strangely following user actions

- Magicicada: A GTK+ frontend for the "Chicharra" part of Ubuntu One client.

- Python: Acá la idea es trabajar en el proyecto Python mismo (lo que puede ser código Python o C, o incluso no código sino documentación, etc.), no hacer cosas con Python.

- Twisted a Python 3: Estoy empujando el migrar Twisted (an event-driven networking engine) a Python 3. Esto no es un proyecto en sí, sino que está en el marco de Twisted mismo.
 
Así que ya saben, si les interesa meterse en alguno, me avisan. En general la coordinación sería remota (IRC, IM), así que no necesitan estar en Buenos Aires...


PyCamp 2011, en La Falda

Python — Martes 29 de Marzo de 2011, 21:32


El fin de semana pasado, que era largo  (¡cuatro días!), lo pasé en La Falda, Córdoba, junto con un montón de gente copada, disfrutando del cuarto PyCamp de Python Argentina.

No voy a explicar de nuevo que es un PyCamp, pero pueden ver mis posts de las ediciones anteriores(acá, acá, y acá).

Viajé en micro durante la noche, así que tempranito ya estaba allá... es más, fui el primero en llegar. Luego fueron cayendo un par más, pero había mucha gente varada en Córdoba Capital por un paro de transporte (gente de Córdoba mismo, y gente de otros lados que cambiaban de micro allá).

Pero más tarde terminaron llegando, y entre una cosa y la otra nos fuimos terminando de empezar a organizar. Así que almorzamos, y arrancamos contando los proyectos que queríamos empujar, quienes éramos, etc.

Después de comer arrancamos varias personas laburando en la CDPedia, un proyecto al que le dedicamos buena parte de los cuatro días. La verdad es que tantas horas invertidas tuvo un resultado bárbaro: corregimos varios problemas, le agregamos muchas características, e incluso terminamos todo lo necesario para sacar la versión 0.7; sólo nos queda limar algunos detalles y ya estaríamos sacando la versión final para distribuir y ver si todavía estamos a tiempo de que Educ.ar las distribuya este año.

Trabajando

El viernes arrancó el día conmigo dando una charla de Twisted que no era mía. Había mucha gente que quería aprender algo de Twisted, y se iba a utilizar en varios proyectos, entonces se me ocurrió, aprovechando que teníamos un microproyector que había traído Achuni, dar la charla que Lucio preparó para las Charlas Abiertas de La Tribu.

Uno de los proyectos de Twisted era seguir portándolo a Python 3, que yo empujaba. Nueces se copó y laburó en esto mismo, conmigo. Durante el día logré terminar un branch que había comenzado durante el sprint en PyCon, y Nueces también logró terminar su parte, generando varios parches. Fue bastante productivo, y encima lo que hice yo y parte de lo que hizo Nueces fue tomado por los desarrolladores del proyecto y metido en trunk (a esta altura ya debe estar metido todo).

Esa noche salimos con Perrito y Joac a comprar un Legui, pero no encontramos, así que nos volvimos al hotel con fernet, coca cola e hielo, y estuvimos varios jugando a un juego de computadora, en red, que no conocía y que me encantó: Armagetron Advanced, que es un juego que salió de la película Tron.

El sábado se hizo un bug day doble, de Python y Django, tanto presencial en el PyCamp como remoto, coordinado por IRC. Tengo que preguntarle a Ramiro Morales para ver cómo salió el de Django (él coordinaba ese); el de Python estuvo bastante flojo porque más que corregir bugs estuvimos charlando y discutiendo cómo usar Mercurial aplicado al proyecto de Python, que no es algo sencillo de determinar, y todos los desarrolladores están ajustando el workflow para ver cómo se puede laburar mejor. Así y todo, para mí estuvo productivo porque no conocía casi nada de Mercurial, y me llevé un buen pantallazo general.

A la tardecita hicimos un paseo entre todos: nos fuimos caminando hasta el punto turístico de La Falda: el Hotel El Edén, donde vimos un video con la historia del lugar, tuvimos un paseo guiado, y hasta una ínfima degustación de vino y queso (muy ínfima). No estuvo para nada mal el paseo.

Hotel El Edén

Durante la vuelta, picamos en punta con Perrito y Pablo Mouzo y pasamos por un supermercado para comprar unos vinos, porque esa noche cenábamos en el salón donde trabajábamos (nos traían las pizzas hasta ahí), ya que durante la cena tuvimos la reunión de PyAr número 48. Tratamos varios temas, y la discusión estuvo muy buena, fue una fantástica reunión.

El domingo fue un día mucho más tranquilo, se notaba que estábamos todos muy cansados. Laburé en CDPedia un rato, charlé de varias cosas con varios, pero nada muy intensivo. Durante la tarde hicimos una actividad grupal: fuimos recorriendo los proyectos en los que se había trabajado durante el PyCamp y en unos minutos se contó qué se hizo, qué se logró, etc.

Los que más me gustaron fueron el grafo del wiki de PyAr (un grafo donde los nodos eran las páginas del wiki y se mostraban las relaciones entre ellas, muy bueno), faldatouch (algo desarrollado cien por ciento durante este PyCamp: una biblioteca que ofrece tener muchos punteros (como si fueran de mouse) a una aplicación, pero con la capacidad de manejar estos punteros desde cualquier lado, particularmente desde teléfonos o páginas web), y la biblioteca de moda: Pilas.

Pilas es un framework para hacer juegos, orientado a que sea sencillo e intuitivo de usar (y con la característica de estar en castellano, lo cual simplifica mucho su adopción por alumnos de escuela primaria) pero a su vez muy poderoso. Se hicieron tres cosas muy piolas sobre Pilas en este PyCamp: se armó lo básico para que se pueda internacionalizar (ahora todos los comandos pueden estar en cualquier idioma), se integró con la biblioteca OpenCV (con lo que se puede tener uno o más videos, incluso el que toma la webcam de la compu, como objeto para manejar durante un juego), y se le armó una especie de multisesión exploratoria (basicamente la capacidad de que mucha gente se conecte a una misma máquina y tenga un intérprete interactivo en el mismo espacio de nombres que la máquina que sirve, con lo que se puede explorar Pilas al mismo tiempo por todos los conectados, de forma colaborativa).

Después de esta sesión se armó el segundo torneo del PyCamp: Armagetron Advanced; el primero fue un campeonato de metegol, :)

Y ya nos fuimos aflojando, boludeamos un rato, preparamos las cosas, y nos fuimos yendo de a poquito (todos salíamos a distintos horarios).

Como conclusión: siempre digo que PyCamp es uno de los mejores eventos de Argentina y del mundo... y este no fue la excepción. Ah, acá hay algunas fotos.


Powered by LifeType