Web Frameworks

[Alberto Valverde]

Mario Lacunza wrote:
> El 30 de julio de 2008 16:20, Alberto Valverde<alberto en toscat.net>escribió:
>
>   
>> Mario Lacunza wrote:
>>     
>>> El 30 de julio de 2008 12:35, Alberto Valverde<alberto en toscat.net
>>> escribió:
>>>
>>>
>>>       
>>>> Mario Lacunza wrote:
>>>>
>>>>         
>>>>> (...)
>>>>> Pues no, sirve bastante!
>>>>>
>>>>> Yo por ejemplo he visto q la instalacion de Django es mucho mas
>>>>>           
>> sencilla
>>     
>>>> q
>>>>
>>>>         
>>>>> la de TG (q instala medio repositorio de paquetes!!)
>>>>>
>>>>>           
>>>> Entonces supongo que instalar Ubuntu, por ejemplo, debe ser harto
>>>> complicado... ;)
>>>>
>>>> Alberto
>>>>
>>>>
>>>>         
>>> No para nada, demora menos q una instalacion de WinXP.
>>>
>>> La comparacion era xq otros FW solo instalaban su paquete referido y no N
>>> mas... y si sabemos q cada uno de esos son proyectos independientes cada
>>>       
>> son
>>     
>>> su ciclo de desarrollo cada uno con su time para release......
>>>
>>>       
>> Sí es cierto... pero no entiendo porqué insinúas que éso sea algo malo.
>> Siempre y cuando haya un sistema que se encargue de gestionar las
>> dependencias y versiones de las mismas (pkg_resources) no entiendo
>> porque reutilizar código ajeno, empaquetado por sus desarrallodores, con
>> su propia comunidad detrás (aparte de la que lo usa a través de TG) sea
>> algo que se deba evitar. Más aun cuando el abuelo Zope está siguiendo el
>> mismo camino en la versión 3 ;)
>>
>>
>>
>> Ok, me explico, y pongo como muestra lo q esta pasando con TG, cambio de la
>> version 1 a la 2, las cuales no tienen compatibilidad entre ellas.
>>     
¿Es eso malo? Mira como le va a Windows teniendo que mantener
compatibilidad con Windows 3.1... :D
>> El problema se da, que cualquiera de esos proyectos "componentes" pueden
>> tomar decisiones o caminos q rompan con lo actuado hasta el momento por TG
>> (q creo es lo q sucedio).
>>     

No fue así. Los componentes que han cambiado en TG2 y TG1.1 frente a TG1
no se cambiarón porque los antiguos tomasen distintos caminos sino
porque han surgido alternativas (mucho) mejores (SQLObject->SQLAlchemy,
Kid->Genshi). Aun así, los componentes "antiguos" (y TG1 en sí) se
siguen manteniendo por sus respectivas comunidades aunque sea en modo de
bugfix puesto que varios tenemos aplicaciones en producción que aunque
no interesa migrar (puesto que no es necesaria la nueva funcionalidad o
se ha implementado localmente) sí interesea actualizar en caso de que se
descubra algún fallo de seguridad.
> Si eso pasara supongo q TG tomaria la decision o de romper compatibildad
> entre sus versiones o asumir la mantencion de la libreria adecuandola a sus
> cambios. Lo cual obviamente es otro mundo... ya vimos cual fue su decision
>   
Como he comentado antes, se tomaron las dos decisiones: Por un lado
re-implentar TG2, sin lastres de compatibilidad, para prepararse mejor
al futuro (no porque lo nuevo fuese más "cool", SQLAlchemy realmente le
da mil vueltas a la competencia) y por otro lado mantener TG1 para los
que la tenemos en producción.  Sí, en algunos casos ha habido que fijar
una versión lejos de la actual (cherrypy2) pero no ha habido problemas
en asegurarnos de que siga recibiendo bugfixes por sus respectivas
comunidades.
> Para nada dije, q reutilizar codigo sea malo, sino el Opensource no
> existiria y del cual soy ferviente partidario. Nadie dice q el sistema para
> resolver dependencias de Ubuntu (distro de Linux q uso) sea malo, solo dije
> que la instalacion me parece engorrosa al tener q configurar tantos paquetes
> a diferencia de otros FW q solo instalan su propia libreria.
¿Qué has tenido que configurar exactamente? Debe ser un bug porque a mí
"easy_install turbogears" de lo deja todo muy bonito y  configurado
automáticamente. ;)

>  Creo q es un
> factor a tener en cuenta, si uno es el Server Admin :D
>   
apt-get ~ easy_install. Es decir, cumplen la misma función: Resolver
dependencias. Que yo sepa a los server admin no les ha ido tan mal
dejando que una herramienta se encargue de esconder el "engorro". ¿Has
visto de cuantas dependencias tira un "apt-get install apache2
libapache2-X libapache2-Y" en una instalación fresca? Me gustaría pegar
aquí el ejemplo pero ya los tengo instalados y no me apetece ahora
montar una máquina virtual para poner el ejemplo... ;)

Resumiendo. Lo que quiero decir es que sí, tener que depender de varias
librerías tiene problemas (más sociales que técnicos) pero la ventaja de
poder reutilizar librerías que por sí solas desempeñan mejor la tarea
especifica que a otros frameworks les gusta reinventar (a un ritmo
bastante más lento, por cierto) ampliamente compensa los
inconventientes, IMHO.

Además, a nivel personal: es agradable comprobar que lo que has
aprendido de SQLAlchemy, por ejemplo, lo puedes reutilizar en una
aplicación para el iphone. O que el Request/Response de webob lo tienes
en Pylons, TG2, el mini framework del GAE... o lo puedes utilizar para
ese pequeño web-service que no necesita de todo el peso de un framework,
que Mako lo puedes importar en un script de cuatro líneas para generar
texto.... todo ésto sin tener que instalar la vaca entera.

Salud,
Alberto
_______________________________________________
Lista de correo Python-es 
http://listas.aditel.org/listinfo/python-es
FAQ: http://listas.aditel.org/faqpyes