Etiqueta: rails

  • ¿Sabes cuando usas la doctrina «si funciona, no toques», pero aun así las cosas se rompen por arte de magia de un día para otro?

    Bundle tiene este problema a veces, que no he podido depurar pero que no es la primera vez que me ocurre: debido a que pueden coexistir múltiples versiones de una gema en simultáneo, a veces utilizar un shim (o sea, invocar rspec o rails en la consola sin más, sin especificar bundle exec ni usar el binstub) falla, porque no está usando la versión concreta de alguna dependencia.

    Después de actualizar unas dependencias en nuestro Gemfile, me empezó a salir este mensaje de error:

    /Users/danirod/.rbenv/versions/2.6.7/lib/ruby/gems/2.6.0/gems/bundler-2.2.17/lib/bundler/runtime.rb:302:in `check_for_activated_spec!': You have already activated rspec-support 3.10.3, but your Gemfile requires rspec-support 3.10.2. Prepending `bundle exec` to your command may solve this. (Gem::LoadError)

    Se soluciona usando bundle exec rspec en vez de rspec. No es que tenga fobia a escribir bundle exec antes de mis comandos, pero mi sentido común me dice que si día tras día, escribir rspec funciona, si de repente deja de funcionar de un día para otro, el problema no lo tengo yo. Por no ir, no me iba ni el binstub. O sea, bin/rspec también me da el mismo mensaje de error.

    A veces cuando me pasan estas cosas hago un pristine, o un cleanup. No piques: es una ruleta rusa. A veces se tira 15 minutos limpiando y reinstalando paquetes para luego seguir fallando al ejecutar. En esta ocasión, he optado por tirar una solución más rápida:

    gem uninstall rspec-support
    bundle install

    Si primero elimino todas las versiones de esta gema que hay en mi ordenador, y luego vuelvo a hacer bundle install, me deberá dejar una única versión instalada: la que pida el Gemfile. Me parece una solución aceptable. Esta es mi workstation, y no uso rbenv con software esencial (si tuviese software instalado desde Homebrew que esté escrito en Ruby, probablemente usaría el Ruby de Homebrew, no rbenv). A lo que quiero llegar es a que no pasa nada si elimino todas las versiones de un paquete y luego reinstalo.

  • Recientemente en Ruby on Rails incorporaron un cambio que genera un aviso al arrancar la aplicación en modo producción si el driver de base de datos que está configurado es el de SQLite. El aviso se puede desactivar cambiando un flag de configuración en el production.rb para confirmar que no es un accidente, sino una decisión.

    You are running SQLite in production, this is generally not recommended.

    Debo romper una lanza a favor de SQLite. Tiene sus issues, claro está, pero muchos de ellos pueden entenderse si se lee la documentación técnica.

    Por ejemplo, si nunca te has leído su guía sobre tipos de datos y afinidad de columnas probablemente te sorprenda lo blando que es para validar los tipos de datos durante el INSERT (puedes guardar enteros en columnas creadas como VARCHAR, y viceversa).

    No vale para todo, pero lo he visto muchas veces en producción en circunstancias en las que tiene sentido que esté en producción, y si está justificado, seguiré defendiéndolo con fuerza como alternativa ligera.

  • Pues esta es fácil pero como todo en Git nunca aparente. Va a pasar cuando haga cambios al Gemfile en dos ramas a la vez.

    git checkout HEAD -- Gemfile.lock

    Esto es para traerme el Gemfile.lock que había antes de obtener mi conflicto. Lo importante es que podemos confirmar con un git status que se preserva el Gemfile, así que los cambios en las versiones o librerías siguen ahí.

    Si he metido o quitado una dependencia del Gemfile, ahora ejecuto bundle para que se descargue o se retire del lock por encima de la última versión que había en la rama en la que estoy intentando hacer el merge.

    Si he actualizado la versión de una dependencia del Gemfile, ahora ejecuto bundle update para que se vuelva a reflejar ese cambio en el lock por encima de la última versión que había en la rama en la que estoy intentando hacer el merge.