Intro

En el escenario del popular Jekyll , generador (en los llamados JAMstack) 'Web estático' basado en Ruby: se nos plantea en la práctica diaria la disyuntiva en su ejecución - CLI . Recordar que Jekyll, no deja de ser una 'gema' Ruby (gem).

Caso práctico

jekyll build

vs

bundle exec jekyll build

¿?

Cuestión: ¿que the diferencias hay ? ¿ Pros and cons de ejecutar 'jekyll build' vs 'bundle exec jekyll build' ?

La única diferencia que habría entre

command option

y

bundle exec command option

es que en el primer caso se estaría ejecutando un comando de forma 'global' disponible en tu computadora mientras que en el segundo se estaría invocando a bundle quien leería el Gemfile particular del proyecto en cuestión (en función del directorio de trabajo) y lo combina todo así se haya declarado en la ejecución de la orden.

De tal modo que si has actualizado la última versión de Jekyll (gem update jekyll) pero olvidaste actualizar el Gemfile.lock usando bundle update (que afecta a las gemas en uso en tu proyecto), el propio bundle te alertará de que hay un desajuste en las versiones disponibles, disminuyendo el riesgo de que se pudiera ejecutar Jekyll con gemas de terceros que fueran incompatibles. Otro ejemplo, en el que el uso de bundle es mandatorio, pero no relacionado con Jekyll directamente, es cuando se quiere testear una aplicación Ruby empaquetada como gema y ya instalada en la computadora, para evitar la necesidad de la repetición del proceso de desinstalación/instalación una y otra vez por cada ajuste/modificación, ejecutando bundle exec en la carpeta del proyecto en curso asegura que lo que se ejecuta es el proyecto modificado y no el aquel instalado en el ámbito de todo el sistema en la computadora.

Bailando con diferentes versiones

En otras palabras. jekyll per se usa la gema del sistema (compartida por todxs lxs usuarixs).

Digamos que actualizas Jekyll 3.8 a Jekyll 3.9, entonces todos los proyectos en el sistema con los que habitualmente usas Jekyll de forma 'global' operaran con la nueva versión. Algunos de los cambios introducidos podrían ser incompatibles. ¿Qué hacer si una parte de los proyectos usan la versión 'antigua' de Jekyll y tan sólo una parte puede trabajar de forma compatible con la nueva versión? Habría que ir actualizando gradualmente aquellos proyectos que muestran incompatibilidades hasta lograr hacerlos funcionar con la nueva versión.

El uso de bundle lo facilita, ya que cada proyecto opera así con su propia versión de Jekyll.

Puedes actualizar de la v3.8 a la v 3.9 o revertir a la v3.7 en uno de los proyectos sin afectar a los otros.

Puedes actualizar el proyecto a la v4.1 y despúes a posteriori a la v4.2 para luego revertir a la v4.1 sin afectar a los demás proyectos existentes en el sistema.

Se podría incurrir también en problemas de dependencias. Pongamos que uno de los proyectos usa bundle para instalar un plugin pero no hace lo propio con Jekyll. Y el plugin requiere determinada versión de una gema determinada. Pero el proyecto en cuestión desconoce la versión 'global' de Jekyll (en el sistema) y el hecho de que requiere una versión anterior de la gema.

Bonus :

Es cómodo en este escenario el uso de (Bash) alias :

alias jek="bundle exec jekyll"

jek serve --trace

Jekyll ya incorpora los alias , de hecho :

jekyll b  # ie build
jekyll s  # ie serve

Véase

jekyll --help*

A quien gusta de uso de un Makefile. Funciona tanto en Mac como en GNU Linux como también en Windows instalando la utilidad GNU Make.

s serve:
  bundle exec jekyll serve --trace --livereload
make s
# serving jekyll site...

Y acá una receta mucho más completa , a-la @MichaelCurrin

Fuentes :

• Foro Jekyll : @MichaelCurrin dixit en