Instalar PEAR en Debian Squeeze siendo usuario normal

Estándar

Para un proyecto PHP en el que estoy trabajando necesitaba instalar una versión reciente de PEAR. Como no quería realizar la instalación de manera global para no interferir con el sistema de paquetes de Debian ni utilizar la ya instalada por ser anticuada busqué la forma de hacerlo en un directorio de mi elección.

El proceso

Antes que nada abrimos una terminal que nos de acceso a un interprete de línea de comando.

Necesitamos el archivo phar que contiene el administrador de paquetes PEAR. Lo descargamos de esta URL: http://pear.php.net/go-pear.phar. Teniendo instalado wget u otro gestor de descarga de nuestra elección, ejecutamos:

$ wget http://pear.php.net/go-pear.phar

o lo bajamos directamente usando el navegador web actual.

Por defecto, la versión de PHP 5.3 que trae Debian tiene incorporado el parche Suhosin, el cual agrega seguridad al interprete pero resulta en ligeras incomodidades para los desarrolladores. Por mi parte aplaudo la decisión del equipo empaquetador. En consecuencia, si ejecutamos a continuación $ php go-pear.phar como muchos intuirían veremos que no pasa nada. Ni siquiera un mensaje indicando que el comando no tuvo éxito. Solo si inspeccionamos el archivo /var/log/syslog veremos unas líneas producidas por Suhosin indicando el error ocurrido. Esto pasa porque la configuración por defecto de PHP que trae Debian prohíbe la ejecución del especificado tipo de archivo.

Para sobrepasar este escollo debemos decirle al interprete de PHP que ignore dicha directiva solo por esta ejecución y ejecute el archivo phar indicado:

$ php -d suhosin.executor.include.whitelist="phar" go-pear.phar

Con lo cual la instalación iniciará su curso normal. Solo resta seguir las instrucciones que aparecen en pantalla.

Django y el error “object has no attribute ‘__name__'” al usar objetos invocables

Estándar

El framework web Django acepta como vista (concepto conocido en otros entornos como controlador) cualquier función o clase que cumpla con la interfaz “callable” (o invocable en castellano). Si decidimos emplear esta última forma nos encontraremos con que Django lanza una excepción en principio desconcertante:

AttributeError: object has no attribute '__name__'

¿Pero de donde sale eso? ¿Acaso Django se ha vuelto loco? ¡Si yo definí el método __call__ en la clase! ¡El framework no debería quejarse! ¡#$%&@! :D.

La respuesta a esto y tal vez a los improperios lanzados por el desarrollador 😉 es que en algún lugar de las profundidades del código fuente de Django (en un momento encontré el módulo causante del error pero ahora no lo recuerdo) el mismo está intentando acceder al atributo que menciona la excepción.

Cuando uno define una función en Python mediante la palabra clave def, detrás de bambalinas el interprete agrega el atributo __name__ a la misma (recordemos que en Python todo es un objeto, incluidas las clases y las funciones, y hasta es posible asignar atributos a esta última). Obviamente el framework espera que este atributo exista, es decir, espera una función propiamente dicha y no un objeto invocable.

La solución a esto es definir __name__ a mano, de la siguiente manera:

class Qwerty(object):

    __name__ = 'Qwerty'

    def __call__(self, *args, **kwargs):

        print args
        print kwargs

Personalmente he encontrado este error agregando vistas a la interfaz de administración que el framework genera con la ayuda del paquete django.contrib.admin (tal vez sea solo un bug que afecte a este paquete, debería probar usando objetos invocables en el despachador de URLs). Con esto espero ahorrarle a alguien horas de esfuerzo, desesperación y mechones de pelo. A mi me hubiese encantado :P.