Comprender el archivo Gemfile.lock

Question

Después de ejecutar el comando bundle install, se creó 'Gemfile.lock' en el directorio de trabajo. ¿Qué significan las directivas dentro de ese archivo?

Por ejemplo, tomemos el siguiente archivo:

PATH 
    remote: . 
    specs: 
    gem_one (0.0.1) 

GEM 
    remote: http://example.org/ 
    specs: 
    gem_two (0.0.2) 
    gem_three (0.0.3) 
     gem_four (0.0.4) 

PLATFORMS 
    platform 

DEPENDENCIES 
    gem_two 
    gem_one! 

Qué hacer ' PATH', ' GEM', ' PLATAFORMAS' y '' DEPENDENCIAS describir? ¿Se requieren todos?

Lo que debe contener los subdirectrices ' a distancia' y 'especificaciones'?

¿Qué significa el signo de exclamación después del nombre de la gema en el grupo 'DEPENDECIES'?

Answer 1

Puede encontrar más información sobre ella en el bundler website (énfasis añadido a continuación para su conveniencia):

Después de desarrollar su aplicación durante un tiempo, el registro de la aplicación junto con el Gemfile y Gemfile.lock instantánea. Ahora, su repositorio tiene un registro de las versiones exactas de todas las gemas que utilizó la última vez que supo con certeza que la aplicación funcionó ...

Esto es importante: el Gemfile.lock hace que su aplicación un paquete único de su propio código y el código de terceros que ejecutó la última vez que usted sabe con certeza que todo funcionó. Especificar las versiones exactas del código de terceros del que dependes en tu Gemfile no proporcionaría la misma garantía, ya que las gemas generalmente declaran un rango de versiones para sus dependencias.

Answer 2

en lo que respecta a la marca de exclamación Me acabo de enterar que está en gemas fue a buscar a través de :git, por ejemplo,

gem "foo", :git => "git@github.com:company/foo.git" 

Answer 3

A mi me parece como ruta lista las dependencias de primera generación directamente desde su gemspec, mientras que GEM enumera las dependencias de segunda generación (es decir, cuáles son sus dependencias dependen) y los de su Gemfile. PATH :: remote es . porque confió en un gemspec local en el directorio actual para averiguar qué pertenece en PATH :: spec, mientras que GEM :: remote es rubygems.org, ya que ahí es donde tenía que ir para averiguar qué pertenece a GEM ::especulación.

En un complemento Rails, verá una sección PATH, pero no en la aplicación Rails. Como la aplicación no tiene un archivo gemspec, no habría nada que poner en PATH.

En cuanto a las dependencias, gembundler.com estados:

Runtime dependencies in your gemspec are treated like base dependencies, 
and development dependencies are added by default to the group, :development 

El Gemfile generada por rails plugin new my_plugin dice algo similar:

# Bundler will treat runtime dependencies like base dependencies, and 
# development dependencies will be added by default to the :development group. 

Lo que esto significa es que la diferencia entre

s.add_development_dependency "july" # (1) 

y

s.add_dependency "july" # (2) 

es que (1) solo incluirá "julio" en Gemfile.lock (y por lo tanto en la aplicación) en un entorno de desarrollo. Por lo tanto, cuando ejecuta bundle install, verá "julio" no solo en PATH sino también en DEPENDENCIAS, pero solo en desarrollo. En producción, no estará allí en absoluto. Sin embargo, cuando usa (2), verá "julio" solo en RUTA, no en DEPENDENCIAS, pero se mostrará cuando bundle install desde un entorno de producción (es decir, en alguna otra gema que incluya la suya como una dependencia), no solo desarrollo.

Estas son solo mis observaciones y no puedo explicar por qué todo esto es así, pero agradezco más comentarios.

Answer 4

¿Qué significa el signo de exclamación después del nombre de la gema en el grupo 'DEPENDENCIAS'?

El signo de exclamación aparece cuando la gema se instaló utilizando una fuente que no sea "https://rubygems.org".

Answer 5

Bundler es un administrador de gemas que proporciona un entorno coherente para los proyectos de Ruby mediante el seguimiento y la instalación de las gemas y versiones exactas que se necesitan.

Gemfile y Gemfile.lock son productos primarios de la gema Bundler (Bundler en sí es una gema).

Gemfile contiene su proyecto de dependencia de gema (s), que mencione manualmente con la (s) versión (es) especificada (s), pero esa (s) gema (s) inturn depende de otra (s) gema (s) que se resuelve automáticamente por bundler.

Gemfile.lock contiene una instantánea completa de todas las gemas en Gemfile junto con la dependencia asociada.

Cuando llame por primera vez al bundle install, creará este archivo Gemfile.lock y usará este archivo en todas las llamadas posteriores a bundle install, que asegura que tiene todas las dependencias instaladas y omitirá la instalación de la dependencia.

mismo ocurre cuando se comparte el código con diferentes máquinas

comparte su Gemfile.lock junto con Gemfile, al ejecutar paquete instalar en otra máquina que se referirá a su Gemfile.lock y se salta la dependencia resolución paso, en cambio, se instalará la totalidad de la misma joya dependiente (s) que se utilizó en la máquina original, que mantiene la coherencia a través de múltiples máquinas

¿por qué necesitamos para mantener la coherencia a lo largo de m ultiple máquinas?

• ejecutan versiones diferentes en máquinas diferentes podría dar lugar a la rotura de código

• Supongamos, su aplicación se utiliza la versión 1.5.3 y funciona hace 14 meses
  sin ningún problema, y ​​se intenta para instalar en otra máquina
  sin Gemfile.lock ahora se obtiene la versión 1.5.8. Tal vez está roto con la última versión de algunas gemas y su aplicación va a
  error. Mantener la coherencia es de suma importancia (se prefiere la práctica
  ).

También es posible actualizar la gema (s) en Gemfile.lock utilizando bundle update.

Esto se basa en el concepto de conservative updating

Answer 6

Parece sin documento claro que habla en el formato Gemfile.lock. Tal vez es porque Gemfile.lock es utilizado por el paquete internamente.

Sin embargo, desde Gemfile.lock es una instantánea de Gemfile, lo que significa que toda su información debe venir de Gemfile (o del valor por defecto si no se especifica en Gemfile).

Para GEM, enumera todas las dependencias que introduce directa o indirectamente en el Gemfile. remote bajo GEM dice dónde obtener las gemas, que se especifica en source en Gemfile.

Si no se obtiene una gema de remote, PATH indica la ubicación para encontrarla. La información de PATH viene de path en Gemfile cuando declara una dependencia.

Y PLATFORM es de here.

Para DEPENDENCIES, es la instantánea de las dependencias resueltas por paquete.

Answer 7

Pasé los últimos meses jugando con Gemfiles y Gemfile.locks mucho mientras creábamos una herramienta de actualización automática de dependencias . Lo que sigue está lejos de ser definitivo, pero es un buen punto de partida para entender el formato Gemfile.lock. También es posible que desee verificar el código fuente de Bundler's lockfile parser.

Encontrarás las siguientes partidas en un fichero de bloqueo generada por Bündler 1.x:

GEM (opcional pero muy común)

Estas son las dependencias de origen desde un servidor Rubygems. Ese puede ser el índice principal de Rubygems, en Rubygems.org, o puede ser un índice personalizado, como los disponibles en Gemfury y otros.Dentro de esta sección se verá:

• remote: una o más líneas que especifican la ubicación del índice de Rubygems (s)
• specs: una lista de dependencias, con su número de versión y las limitaciones de ningún subdependencies

GIT (opcional)

Estos son dependencias procedentes de un mando a distancia git dado. Vas a ver una diferente de estas secciones para cada git remote, y dentro de cada sección verá:

• remote: el control remoto GIT. Por ejemplo, git@github.com:rails/rails
• revision: el cometer referencia la Gemfile.lock está bloqueado a
• tag: (opcional) la etiqueta especificada en el Gemfile
• specs: la dependencia git encontrado en este control remoto, con su número de versión, y las limitaciones en cualquier subdependencies

PATH (opcional)

Estos son dependencias de origen a partir de una dada path, incluido en el Gemfile. Vas a ver una diferente de estas secciones para cada dependencia de la trayectoria, y dentro de cada sección verá:

• remote: el camino. Por ejemplo, plugins/vendored-dependency
• specs: la dependencia git encontrar en este mando a distancia, con su número de versión y las restricciones en cualquier subdependencies

PLATAFORMAS

la plataforma Rubí la Gemfile.lock se generó contra. Si alguna dependencia en el Gemfile especifica una plataforma, solo se incluirán en Gemfile.lock cuando se genere el archivo de bloqueo en esa plataforma (por ejemplo, a través de una instalación).

DEPENDENCIES

Una lista de las dependencias que se especifican en la Gemfile, junto con la restricción de versión especificada allí.

Dependencias especificados con una fuente distinta que el índice principal Rubygems (por ejemplo, dependencias de GIT, basado en vía dependencias) tienen una ! que significa que están "clavados" a esa fuente (aunque a veces se debe mirar en el Gemfile para determinar en).

RUBY VERSION (opcional)

La versión de Ruby especificado en el Gemfile, cuando se creó esta Gemfile.lock.Si se especifica una versión de Ruby en un archivo .ruby_version, esta sección no estará presente (ya que Bundler considerará que Gemfile/Gemfile.lock es independiente de la versión de Ruby del instalador).

AGRUPADOS CON (Bundler> = v1.10.x)

La versión de Bundler utilizado para crear el Gemfile.lock. Se usa para recordar a los instaladores que actualicen su versión de Bundler, si es anterior a la versión que creó el archivo.

PLUGIN FUENTE (opcional y muy raro)

En teoría, un Gemfile puede especificar plugins Bundler, así como gemas , que luego se enumeran aquí. En la práctica, no conozco ningún complemento disponible a partir de julio de 2017. ¡Esta parte de Bundler aún está en desarrollo activo!

---

1. https://dependabot.com
2. https://github.com/bundler/bundler/issues/4631
3. http://andre.arko.net/2012/07/23/towards-a-bundler-plugin-system/