2012-02-13 15 views
55

He notado que en rubygems.org muchas de las gemas sugieren que las especifiques por versión principal en lugar de por versión exacta. Por ejemplo ...¿Debo especificar las versiones exactas en mi Gemfile?

The haml-rails gem ...

gem "haml-rails", "~> 0.3.4" # "$ bundle install" will acquire the 
           # latest version before 1.0. 

Sin embargo, en base a la Bundler docs sonaba a mí como que sería mejor para clavar la versión exacta como esto ...

gem "haml-rails", "0.3.4" 

Así que está su gema haml-rails y todas sus dependencias no avanzarán. Si revisa el proyecto en una máquina diferente unas semanas más tarde y ejecuta $ bundle install, tendrá exactamente las mismas versiones de todo lo que especificó.

He visto puntos de liberación de cosas, y pensé que parte de la idea de Bundler era "Bundle.lock" todas sus versiones de gemas.

Pero en rubygems.org usan "~>" mucho así que tal vez me falta algo?

Cualquier aclaración sería muy útil para mí en la comprensión de la gestión de Bundler y la gema.

Respuesta

51

Este es el propósito del archivo Gemfile.lock - ejecutando bundle install con un Gemfile.lock presente solo se instala usando las dependencias enumeradas allí; no vuelve a resolver el Gemfile. Para actualizar dependencias/actualizar versiones de gemas, debe hacer explícitamente un bundle update, que actualizará su archivo Gemfile.lock.

Si no hubiera un Gemfile.lock, implementar un código para la producción sería un problema importante porque, como usted menciona, las dependencias y las versiones de la gema podrían cambiar.

En resumen, generalmente debe estar seguro utilizando el operador de restricción de versión pesimista (~>) como recomienda rubygems.org. Solo asegúrese de volver a ejecutar sus pruebas después de hacer un bundle update para asegurarse de que nada se rompa.

Hay un nice article de Yehuda Katz que tiene un poco más de información en Gemfile.lock.

+0

De acuerdo, las gemas se mantienen en sus versiones establecidas registradas en Gemfile.lock. Entonces, ¿cuál es el propósito de agregar "~>"? ¿Cómo es eso ventajoso? – Ethan

+2

@ethan RubyGems tiene un [documento] (http://rubygems.rubyforge.org/rubygems-update/Gem/Version.html) que lo explica (ver la sección "Prevención de la catástrofe de la versión"). La esencia de esto es que solo permite que el último número entero en el número de versión aumente (por ejemplo, '~> 1.0.5' permite la actualización a la versión 1.0.9999, pero nunca a 1.1.x). El mecanismo es para permitir que las gemas se actualicen, pero sin introducir incompatibilidades que pueden romper las cosas (se supone que las gemas están siguiendo la política de "Rational Versioning" que vincula los contornos). –

+1

@ethan Aquí hay un par de enlaces más en el sitio RubyDocs sobre el "[operador pesimista] (http://docs.rubygems.org/read/chapter/16#page74)" (~>) y [versiones racionales] (http : //docs.rubygems.org/read/chapter/7). –

5

Definitivamente diría que use los números de versión exactos. Probablemente siempre puedas simplemente bloquearlo en una versión principal, o nunca especificar ninguna versión, y estar bien, pero si realmente quieres ese nivel de control fino y tener 100% de confianza en tu programa cuando se ejecuta en otras máquinas, usa los números de versión exactos.

He estado en situaciones donde no se especificó el número de versión exacto, y cuando yo o alguien más hice un bundle install, el proyecto se rompió porque fue a una versión más nueva. Esto puede ser especialmente malo cuando se implementa en producción.

Bündler hace bloqueo en sus especificaciones de la gema, pero si usted está diciendo que sólo tiene que utilizar una versión mayor, entonces se bloquea de que en. Así que es sólo sabe "Oh la versión está bloqueada en al> 0,1" o lo que sea, pero no "Oh, la versión está bloqueada específicamente en 0.1.2.3".

+8

Si 'Gemfile.lock' está presente, entonces Bundler sí, de hecho, sabe qué versión específica instalar (razón por la cual' Gemfile.lock' debe almacenarse en el repositorio junto con 'Gemfile'). – mipadi

+1

Haciendo una 'actualización de paquete ' aunque puede terminar actualizando mucho más de lo que pensaba, incluso si el 'Gemfile.lock' está presente, y esa puede ser una situación peligrosa y pegajosa. – MrDanA

+0

Estoy de acuerdo con la recomendación de los propios RubyGems sobre este tema: simplemente use la restricción pesimista (~>). Esto alienta a toda la comunidad a acumular versiones semánticas, lo cual es algo bueno, y entre esto y las características de estabilidad incorporadas de Gemfile.lock, sus bases deberían estar más que cubiertas. – user456584

Cuestiones relacionadas