Las personas que usan Ruby en general tienen una tendencia a instalar diferentes versiones de Ruby, administrar sus paquetes (o gemas), y gestionar las dependencias de sus gemas.
Algunas plataformas ya tienen Ruby pre-instalado o disponible como un paquete propio. Muchos rubystas no utilizan estas versiones, o si lo hacen, solo lo utilizan para preparar otra instalación o implementación de Ruby. En lugar de eso, los rubystas tienden a instalar un gestor de Ruby para poder instalar diferentes versiones y poder cambiar dependiendo del entorno de cada proyecto.
Los siguientes son gestores populares de entorno de Ruby:
Ruby fue creado por Yukihiro “Matz” Matsumoto, quien se mantiene como una especie de BDFL, aunque recientemente está cambiando. Como resultado, la implementación de referencia de Ruby es llamada MRI (Matz’ Reference Implementation), y cuando se habla de una versión de Ruby, se está haciendo referencia a la versión inicial de MRI.
Las tres versiones mayores en uso de Ruby son:
El cambio de 1.8.7 a 1.9.x es un cambio mucho mayor que de 1.9.3 a 2.0.0. Por ejemplo, la serie 1.9 presentó codificaciones (encodings) y un bytecode VM. Todavía hay proyectos que utilizan 1.8.7, pero se están convirtiendo en una pequeña minoría, debido a que la mayor parte de la comunidad está utilizando como mínimo 1.9.2 o 1.9.3.
El ecosistema de Ruby disfruta de muchas diferentes implementaciones de Ruby, cada una con fortalezas únicas y estados de compatibilidad. Para ser claros, las diferentes implementaciones están escritas en diferentes lenguajes, pero todas son Ruby. Cada implementación tiene hooks especiales y características extra, pero todas interpretan archivos Ruby de forma normal. Por ejemplo, JRuby está escrito en Java, pero no necesitás saber de Java para poder utilizarla.
Muy maduras/compatibles:
Medianamente maduras/compatibles:
No tan maduras/compatibles:
Las implementaciones de Ruby pueden tener su propio número de versión de release, pero siempre apuntan a una versión específica de MRI para poder tener compatibilidad. Muchas implementaciones tienen la habilidad de trabajar en diferentes modos (por ejemplo, modo 1.8 o 1.9) para especificar a qué versión de MRI están apuntando.
Muchas implementaciones de Ruby dependen en gran medida de Ruby Spec. Ruby no tiene una especificación oficial, por lo que la comunidad ha escrito especificaciones ejecutables en Ruby para poder testear la compatibilidad de sus implementaciones con MRI.
RubyGems es un manejador de paquetes/comunidad de Ruby. RubyGems viene incluido con Ruby, por lo que no hay necesidad de instalarlo por separado.
Los paquetes de Ruby son llamados “gemas” (“gems”), y pueden ser alojados por la comunidad en RubyGems.org. Cada gema contiene su código fuente y algo de metadata, incluyendo cosas como la versión, dependencias, autor(es), y licencia(s).
Bundler es una herramienta para resolución de dependencias de gemas. Utiliza un archivo llamado Gemfile en cada proyecto para poder organizar sus dependencias, y luego poder agregar dichas dependencias y sus dependencias de forma recursiva. Hace esta acción hasta que resuelve y descarga todas las dependencias, o se detiene si es que un conflicto aparece.
Bundler eleva un error si encuentra dependencias conflictivas. Por ejemplo, si la gema A requiere la versión 3 o mayor de la gema Z, pero la gema B requiere la versión 2, Bundler va a notificarte sobre dicho conflicto. Esto es extremadamente útil ya que varias gemas hacen referencia a otras gemas (de las cuales puede referenciar a otras gemas), lo cual puede formar un gran grafo de dependencias para resolver.
Testing es una parte grande dentro de la cultura de Ruby. Ruby incluye su propio framework de testing llamado minitest (o TestUnit para la versión 1.8.x de Ruby). Hay varias librerías de testing con diferentes objetivos.
La comunidad de Ruby se enorgullece de ser una comunidad abierta, diversa y acogedora. Matz mismo es extremadamente amigable, y en general la generosidad de los rubystas es increíble.
¿Tienes una sugerencia o rectificación? Abre un issue en el repositorio de GitHub, o haz un pull request tu mismo
Originalmente contribuido por Jon Smock, y actualizado por 2 colaborador(es).