Al fin vacaciones

Ayer, por fin, salí a vacaciones. La semana que acaba de pasar ha sido la más dura de los últimos meses. Todos los exámenes y trabajos que presentar en la universidad se juntaron. De verdad me alegra que ya se haya acabado. Lo bueno es que el miércoles me voy de vacaciones; iré para Medellín, dónde últimamente han vivido mis abuelos. Casi toda mi familia irá para Medellín a pasar el fin de año, después iremos a Coveñas, un agradable pueblo en la costa atlántica, estoy bastante ansioso por viajar, la verdad es que un buen descanso me vendrá muy bien.

Bien, aunque ya salí a vacaciones en la universidad, aún no estoy completamente libre; todavía tengo cosas pendientes en el trabajo. Había pensado terminar y presentar lo que tenía pendiente esta semana, pero debido a tanta cosa en la U, me tocó aplazarlo. Ahora tengo que hacerlo antes del miércoles, aunque no me preocupa, lo que me falta esta de un pelo.

Algo que seguro influyo para que esta semana fuera tan complicada, es el hecho de que el fin de semana pasado no hice nada. Bueno, no hice nada relacionado con la Universidad ni el trabajo. El fin de semana pasado me dedique a dos cosas, por un lado estuve compilando Gnome desde el CVS y por el otro estuve intentando cambiar el skin de la página del GLUC.

Compilar Gnome desde el CVS ha sido menos complicado de lo que pensé, aunque eso si, bastante demorado. Jhbuild facilita mucho el trabajo, incluso tiene una interfaz gráfica (aunque yo lo usé desde la consola), y un práctico icono en el área de notificación. También estuve haciendo un archivo de módulos para poder compilar mono usando jhbuild. Lo práctico de esto es que puedo actualizar, recompilar e instalar todo de nuevo con sólo escribir un comando. Además todo se instala en un entorno aparte, con lo cual puedo tener conviviendo mis versiones estables de Mono y Gnome con las versiones de CVS y SVN. El único inconveniente es tal vez que cuando pongo a correr ambos al tiempo se consume bastante memoria. Por ejemplo cuando corro Mono Develop (corriendo sobre gtk# 2.8 y gnome 2.13.3) dentro del entorno estable.

He aquí algunos screenshots de Jhbuild:

Screenshots de Gnome CVS:

Herramientas para Python

Por estos días que he estado trabajando bastante en DeStar, estuve buscando algún buen IDE para programar en Python. Hasta ahora he estado programando con JEdit, un excelente editor de textos que poco tiene que envidiarle a Emacs o Vim y que es muy fácil de usar. La combinación de JEdit con gnome-terminal, Pdb y PyLint es bastante cómoda, sin embargo, quería probar algo un poco más integrado, así que me decidí a probar Pydev. PyDev es un plugin para el maravilloso Eclipse, el cual, por cierto, funciona perfectamente bajo GCJ, la implementación libre de Java.

PyDev tiene características bastante impresionantes:

• Resaltado de sintaxis, explorador de clases y resaltado de errores. Bueno, esto es lo básico de todo IDE. Siendo Python un lenguaje dinámico, el resaltado de errores se hace utilizando PyLint. PyLint es bastante impresionante y configurable, puede detectar errores que van desde un objeto no declarado hasta prácticas feas de programación como líneas muy largas o nombres de variable muy cortos.
• Code Completion, que no es más que el clásico asistente que ayuda sugiriendo qué se puede colocar digamos después de un punto. Muy útil a la hora de recordar nombres de métodos.
  
• Integración con Bicycle Repair Man, la herramienta para refactorizar código en Python. Esta si que es una gran característica que no había podido usar con JEdit. Por más que exista el HyperSearch y todo, este tipo de herramientas agilizan mucho las cosas.
  
• Depurador gráfico. Esta si que es una de las mejores características. Sé que Pdb es bastante fácil de usar, pero la verdad es que, a la hora de depurar, no hay nada como tener una buena perspectiva gráfica de todo lo que esta sucediendo. El depurador fue la principal razón que tuve para buscar un IDE y la verdad es que Eclispe con PyDev hacen un excelente trabajo en ese sentido.
  
• Integración con Subversion. Bueno, esto no es de PyDev, sino más bien de Subclipse, el plugin de Subversion para Eclispe. La integración es muy buena, cada cambio en la copia local con respecto al repositorio se muestra con algún icono, casi como tener un "svn st" en tiempo real. Por otra parte, todos los comandos usuales en SVN tienen su equivalente gráfico.
  

Desafortunadamente no todo es perfecto. PyDev tiene algunos problemas que pueden llegar a ser molestos. Por una parte, PyDev no tiene soporte para PTL, el lenguaje de plantillas de Quixote, es decir que toca decirle a PyDev que maneje los archivos PTL como archivos normales de Python; aunque el depurador funciona bien para los PTLs, otras características como PyLint y el explorador de clases no lo hacen bien (En JEdit en cambio si funcionaba gracias al plugin Code Browser). Algo similar pasa con los archivos que tienen extensión diferente a ".py", solo que en este caso simplemente no funciona nada, la única solución que he encontrado en este caso es renombrar los archivos temporalmente.

También he probado otras alternativas como JPyDebug, un plugin de Python para JEdit que agrega funciones de depuración, PyLint y explorador de clases, pero desafortunadamente este plugin sólo funcionaba cuando quería y decidí quitarlo. En fin, creo que probaré con PyDev por un tiempo y si no me gusta seguiré con el cómodo JEdit + Consola.

En resumidas cuentas: Eclipse + PyDev + Subclipse hacen un gran equipo

Detesto los paquetes - Parte 2

Definitivamente creo que la forma en que se están manejando los paquetes de software en las distribuciones de Linux es uno de los más grandes problemas que tiene la adopción del Software Libre en el escritorio. Y cuando hablo de las distribuciones de Linux hablo de todas, incluyendo Debian y Gentoo que se jactan de tener los mejores sistemas de paquetes.

Me molesta que cada distribución tenga un formato diferente de paquetes, e incluso las que comparten uno (como RPM), lo hacen incompatible. Esto lleva a que la labor de empaquetado se tenga que hacer una y mil veces. Un programa como Firefox tiene que ser empaquetado tantas veces como distribuciones hay. ¡Qué enorme gasto en trabajo de los colaboradores!, si las cosas funcionaran como deben, el desarrollador del programa debería empaquetar una vez y el paquete debería servir para cualquier distribución (en parte esto es lo que ocurre cuando se distribuye el código fuente, pero compilar definitivamente no es lo adecuado para un novato).

El hecho del empaquetado esté en manos de los que distribuyen y no de los que desarrollan el software es un problema mucho más grave de lo que parece. He aquí algunas razones:

• No importa qué tan grande sea el ejercito de empaquetadores que se tenga, no es posible empaquetar todo el software. Por más que la gente de Debian diga que tiene n-mil paquetes, basta con mirar un poco gnomefiles.org para darse cuenta de que existen muchísimos programas sin empaquetar. El problema es aún peor con las distribuciones que no cuentan con la suerte de tener tantos colaboradores, simplemente tienen que resignarse con no tener el suficiente software, porque así es el sistema. Todo lo que no está empaquetado es difícil de instalar y no se integra bien con el resto de la distribución; esto hace que los usuarios muchas veces opten por simplemente no instalar lo que no está empaquetado, de hecho, tengo muchos amigos que no instalan nada que no se pueda apt-get installar, de ahí es donde surge la frase muy comúnmente escuchada que dice "Si no está en Debían, no exite"; la verdad es que se están perdiendo de un montón de programas.
• Aún cuando se tenga un cierto programa empaquetado, no siempre se puede tener la última versión. Esto es bastante frustrante. ¿Por qué cuando sale el último Firefox no puedo probarlo porque no está empaquetado aún? El problema es peor aún con las versiones anteriores de la distribución. Por ejemplo, si yo uso Ubuntu Warty, nunca voy a disponer del paquete para Firefox 1.5, aún cuando si me bajo el binario de Mozilla.org si funciona. Es decir que los usuarios de Warty van a estar condenados a usar versiones viejas de todo el software y la única forma de conseguir un programa nuevo es actualizando toda la distribución. En otros casos es peor; en donde hay que pasarse a una versión inestable para poder probar el software nuevo. ¿Acaso suena lógico tener que actualizar a una versión inestable todo el sistema operativo, incluyendo Gnome, Gtk, etc sólo porque quiero probar el nuevo Firefox? Todo esto simplemente porque las personas de las distribuciones no quieren hacer los paquetes. Si el empaquetado estuviera en manos de los desarrolladores, la historia sería otra. Por ejemplo, la mayoría del software para Windows funciona desde la versión 95 hasta Vista ¿Que pasaría si para instalar un programa de Windows nos pidieran que obligatoriamente nos actualicemos a Vista? La actualización semestral de las distribuciones me parece una excelente idea, pero hay que aceptar que los usuarios normales no actualizan su sistema operativo cada 6 meses, eso es más bien para complacer a los geeks. Privar a los usuarios no expertos de ciertos programas no me parece una buena idea. Aunque hay casos en los que toca realizar la actualización, por cuestiones de dependencias, en muchos otros no, como el de Firefox.
• Los sistemas de paquetes son completamente hostiles al software que no es libre y esto aleja a los ISVs. En mi opinión, no se puede tener una verdadera aceptación en el escritorio si los usuarios no tienen la libertad de escoger usar programas propietarios además de los libres. Además, ¿Qué pasa con los programas que no son del todo libres pero que su licencia tampoco es tan agreste como las típicas licencias propietarias? un ejemplo de este tipo de software es SciLab. Peor aún, no cualquiera puede ser empaquetador de una distribución, a veces hay que seguir rituales casi religiosos para poder hacerlo (véase cómo ser un DD). Los empaquetadores son los que deciden qué software se empaqueta. ¿Qué pasaría si para distribuir un programa de Windows hubiera que pedirle permiso a Microsoft? (Sé que la comparación es insensata, por favor no armar un flame por esto). En fin, me gusta la frase de la web de Zero Install: "You don't need to be blessed by a distribution (or anyone else) to be part of Zero Install".

Bueno, ya me desahogué un poco, la verdad es que a veces es bastante frustrante todo esto, lo peor es que a poca gente le interesa el problema, incluso he visto como la propuesta de crear un autopackage para Mono no sonó mucho. Por cierto, en el título dice "Parte 2" esto es porque hace poco más de un año había escrito sobre este mismo problema, y mencionaba algunas alternativas interesantes como Zero Install y Autopackage.

En resumidas cuentas: ¡Al diablo con el APT!