Oj: Incluye bigdecimal como una dependencia de tiempo de ejecución

Me alegra tener más discusión.

¿Hubo alguna razón particular por la que se agregó en 3.10.9?

Había. #613 señaló que el ruby ​​2.7.1 en una de las imágenes alpinas esperaba que se incluyera bigdecimal en las dependencias.

Entendido. Eso tiene sentido. Creo que su último lanzamiento aborda el problema; lo hizo por mi situación. Sin embargo, también estoy usando RBENV e instala las dependencias predeterminadas para cada versión de Ruby. Es posible que deba probar las otras situaciones descritas anteriormente para asegurarse de que funcionen también.

FYI: Cambiar oj de 3.10.8 a 3.10.12 genera NoMethodError: undefined method 'new' for BigDecimal:Class en una de nuestras aplicaciones de rieles en el arranque, en shoulda-matchers 2.8.0 …/matchers/active_model/validate_inclusion_of_matcher.rb:251 bajo ruby ​​2.5.8.

¿Se está cargando la versión incorrecta de bigdecimal?

Sí, esto suena como un problema con el uso de bigdecimal 2.0 con Ruby 2.5.

Una solución sería anclar bigdecimal a 1.3.4 en la aplicación Rails Gemfile _y_ recordar cambiar la versión bigdecimal cuando actualice la aplicación para usar un nuevo Ruby en el futuro.

Esta solución es onerosa. No creo que debamos impulsar este trabajo adicional en todos los equipos que usan la gema oj.

En su lugar, si eliminamos la declaración de dependencia de tiempo de ejecución de oj para bigdecimal, las aplicaciones posteriores no tendrán bigdecimal en su paquete de gemas y seleccionarán automáticamente la versión bigdecimal incluida con Ruby.

Estoy feliz de poner en lo que alguna vez funciona para la gente. La dependencia actual de Oj es de 1.0 a 3. ¿Obliga eso a una versión en Rails?

Estoy con @orien en este caso, prefiero no tener una versión gema de stdlib definida como una dependencia. Mi comprensión del código es que el requisito de Bigdecimal es una peculiaridad para Rubinius. https://github.com/ohler55/oj/blob/f300fa5c8cb33616c8282a9fcb8d947fde947e00/lib/oj.rb#L5 -L11
@ ohler55 dijiste aquí que Rubinius ya no es compatible , ¿tendría sentido eliminar la dependencia fuerte de BigDecimal ya que supongo que no es necesario?

Lo intentaré y empujaré a la rama de desarrollo. Si las partes interesadas pueden probarlo, sería útil.

Retirado y empujado.

Acabo de actualizar mi Gemfile con gem 'oj', git: 'https://github.com/ohler55/oj.git', branch: 'develop' y luego ejecuté bundle update . Eliminó las referencias en gemfile.lock :

BORRADO

bigdecimal (2.0.0)

oj (3.10.12)
      bigdecimal (>= 1.0, < 3)

Realicé pruebas de rspec... todo pasó sin problemas, usando Rails 6.0.3.2, Ruby 2.7.1, RBENV.

Siendo yo quien inició la discusión, me di cuenta de que esto podría ser más bien un problema mío, usando el paquete alpino incorrecto.

En alpine, hay ruby que es el mínimo, sin incluir las bibliotecas estándar. Por otra parte, hay ruby-full , que es un metapaquete que incluye ruby más los paquetes que cubren la biblioteca estándar. Esto fue un poco contrario a la intuición para mí, ya que esperaba que un paquete ruby cubriera la biblioteca estándar completa.

Usar ruby-full en alpine funciona para mi caso de uso y haría que no sea necesario requerir bigdecimal . Si debe ser requerido todavía es otro punto. No veo ningún daño en que sea necesario. Al menos no sin versión. Requerirlo con una versión específica podría causar una ruptura de las gemas, que requieren tanto oj como una versión específica de bigdecimal, como lo mencionan varios otros aquí.

Discusión relacionada ver https://github.com/simplecov-ruby/simplecov/issues/917

Me alegro de que hayas resuelto ese problema. Creo que eso resuelve el problema para todos. Volveré a lanzar de nuevo a la forma anterior, pero con el rubinius depende eliminado.

Publicado

se puede cerrar esto?

se puede cerrar esto?

Eso creo. No he tenido ningún problema desde la última versión.

Gracias a todos. Agradezco la discusión.