El día 16 de junio de 2008 5:27, Luis Lavena <[EMAIL PROTECTED]> escribió: > 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. > esto es totalmente falso, yo tengo simultaneamente ruby1.8 y 1.9, tambien firefox 2 y 3, provistos por la distribucion.
> 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. > > "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). > > 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). > si, pero ellos lo llaman "politica" salu -- --Gabriel Máculus-- _______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
