2008/6/16 Luis Lavena <[EMAIL PROTECTED]>: > 2008/6/16 Diego Algorta Casamayou <[EMAIL PROTECTED]>: > > Hola amigos, > > > > Nada más quería pasarles este link a un MUY buen post de Luke Kanies, > > creador de la espectacular herramienta de administración centralizada > > Puppet (desarrollada 100% en Ruby, desde mucho antes que Rails > > existiera). > > > > http://www.madstop.com/ruby/ruby_has_a_distribution_problem.html > > > > Gracias por el link Algorta. > > > Estoy de acuerdo con él. :( > > > > Respetuosamente discrepo: > > "The reason is that rubygems installs in a location that Ruby doesn't > search by default. The reason for that is that apparently this one > guy, somewhere, wanted to have multiple versions of a given package > installed at once. Who wants this? Let's just say it's not the guys > who are distributing hundreds and thousands of copies of their > software." > > No voy a entrar en una batalla entre Windows vs. La distro Linux de > selección, pero en Windows, muchas veces uno puede tener multiples > versiones (v1, 1.5, 2, 3, etc) del mismo programa instalado > simultaneamente y coexistiendo pacificamente. En *nix esto no es > posible.
En Linux esto si es posible y de varias maneras. Por ejemplo: 1) Usando un sufijo. (ruby-1.8.6 y ruby-1.8.7). 2) Cambiando el path de instalación. /usr, usr/local, /usr/ruby/local, /opt/ruby. 3) Si solo lo necesitas una version X.X de Y para probar algo; no necesitas instalar en el sistema --"make install"-- y podes ejecutar la aplicacion Y desde el dir de compilacion. 4) ... Seguro que hay mas formas ... > > Durante la vida de una aplicación (que si uno es un buen developer) > espera que versión tras versión vaya mejorando -- más en OSS cuando > uno tiene contributors los cuales aportan cosas interesantes. > > Si es verdad que uno trata de "pegarse a versiones especificas" para > no comprometer la estabilidad de su proyecto, pero para eso esta > require_gem (que es deprecated) o gem y "= X.Y.Z" por darles un > ejemplo. Lo contrario también aplica. Si te apegas a versiones particulares, podes tener problemas si otra persona usa una mas nueva. No va funcionar tu proyecto. La recomendación que yo haría es estudiar bien quien es el developer de la gema que vas a usar y ver si suele introducir cambios muy toscos que puedan llegar a afectar tu producto a futuro. > > "The truth is, most Rubyists don't even seem to use gems this way -- > they tend to create a vendor subdirectory in their project, and then > install their gems there." > > Ah, "aguante rails", el vendor no era tan popular antes de Rails, > menos que vos ibas a freezar los componentes externos dentro de tu > proyecto. > > Por que? simple y sencillo: si yo freezo un LGPL dentro del vendor de > mi proyecto y este no es LGPL compatible, tengo que cambiar la > licencia de este para que concuerde. Lo mismo si yo no estoy liberando > el source de mi proyecto y uso un componente GPL (hay varias gemas con > ese tipo de licencia). > > Al final, si el usuario ya tiene instalada la gema que yo tengo > freezada estoy no solo duplicando sino incrementando el riesgo a largo > plazo de haber olvidado alguna dependencia huérfana y por ende, lo que > creo es mi app bien freezada es en realidad la mitad de esta. > > Caso concreto es el generator de Dr. Nic Willians, que es usado por > Merb para los generators pero que si uno no contaba con la gema de > ActiveSupport instalada no funcionaba (o sea, tenias que tener Rails > instalado). Podes instalar ActiveSupport solo. No necesitas tener Rails instalado. Active* son gemas que viven en forma individual. > > > En síntesis, mucho del ranting de este muchacho va al modelo de > versioning de RubyGems, y la incapacidad del propio ruby de manejarlo. > Pero también cita ejemplo de como "desarmar" una app de rails y poner > distintos componentes en las distintas estructuras de un sistema > Linux. > > Ruby 1.9 por su parte incorpora RubyGems, asi como la "distro" de ruby > en Windows. Cada distro de Linux hace lo que cree conveniente, y > debian hace destrozos (seamos honestos, romper un paquete en tantos > pedacitos es de carnicero). Totalmente de acuerdo. ! :( . Entre Ruby, cada tipo de SO y cada distro en particular están haciendo un quilombo de novela. :(. > > Uno de los problemas es que la gente no aprende sobre politicas de > versionado y ve las reglas de los paquetes que usa, por ende, termina > siempre requiriendo la ultima version del componente que es > incompatible por X razon con la anterior. > > Un ejemplo concreto fue lo que me paso con win32-service y > mongrel_service, que entre 0.5.x y 0.6.x hicieron cambios que > afectaban el funcionamiento (eran major changes, no minor) y por esto, > muchos usuarios fueron afectados. > > Conclusión: vendor everything es un shortcut a un problema > comunicacional y organizativo mayor. Si los developers no aprenden un > poco, mucho no se puede hacer al respecto. > > Dato anegdotico: Radiant incorporaba en su primer momento de una > tecnica para crear gemas basada en mi trabajo de Freezado y gemas para > Rails, ya poco queda de eso, pero en el spec de la gema perfectamente > pueden entrar aquellas dependencias especificas de las que tu > aplicación Rails depende. > > Saludos, > -- > Luis Lavena > AREA 17 > - > Human beings, who are almost unique in having the ability to learn from > the experience of others, are also remarkable for their apparent > disinclination to do so. > Douglas Adams > _______________________________________________ > Ruby mailing list > [email protected] > http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar > Saludos. -- -- --<自由編碼人>-- Ing. Matias Pablo Brutti Security Consultant Email : [EMAIL PROTECTED] Site: http://www.freedomcoder.com.ar
_______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
