Ruby 3.4 and BigDecimal.

[mullermp]

I have recently become aware of Ruby 3.4 dropping support for BigDecimal and that it must be installed as an additional dependency. We tried adding the BigDecimal dependency to our gems and broke a large customer. This is an issue for them because BigDecimal is a native extension gem, and they don’t have build tools installed. I am wondering if it’s possible for you or someone on the Ruby core team to publish a pre-built native gem to alleviate the issue? I think moving functionality to gems is great however cases where it’s a native extension poses a barrier.

I understand that it's hard to support all platforms. Are there any alternatives to this?

[hsbt]

@mullermp Thanks to share your concern.

I have questions:

This is an issue for them because BigDecimal is a native extension gem, and they don’t have build tools installed.

I understood that situation. But Ruby users usually do install native extension to use Rails or other software. In my experience, installing build tool is common way to use Ruby language. Why they couldn't that?

I am wondering if it’s possible for you or someone on the Ruby core team to publish a pre-built native gem to alleviate the issue?

There is no plan to do that now for gem install bigdecimal. But we have "bundled gems" technic for bigdecimal. It means Ruby 3.4.0 will have pre-build bigdecimal gem with ruby installation. Is it enough that?

[mullermp]

Thanks for your response. We have a large customer that does not have the ability to install native extension gems because those developer tools are not available on their instances.

Thanks for more information about bundled gems. It sounds like with Ruby 3.4, we can still require big decimal if Ruby was installed and it does not need to be fetched from RubyGems using bundler. Is that correct? If so, this can be closed.

[alextwoods]

Having bigdecimal as a bundled gem available in standard ruby installs does not help users who are using bundler to manage dependencies. If bigdecimal is listed as a dependency by any of the gems in a users Gemfile a bundle install will fail if they cannot build and install native extensions. There is a number of users for the AWS SDK for Ruby that do not have environments where they can install native gems - for example, it is common to use slim docker images that do not contain build tools to keep image sizes down.

[junaruga]

We have a large customer that does not have the ability to install native extension gems because those developer tools are not available on their instances in their production instances.

I can assume that some people don't install the developer tools for a better security or to save the size of the instances.

However, why don't the following steps work in the some people' case?

For example, the steps may be like this in Amazon Linux 2023.

$ sudo dnf -y install gcc foo-devel # Install the compiler via the distro package or install the compiler from the source.
$ gem install bigdecimal
$ sudo dnf -y uninstall gcc foo-devel [+ perhaps other dependent packages] # Uninstall the compiler via the distro package or uninstall the compiler built from the source.

And save the instance, and deploy.

[hsbt]

it is common to use slim docker images that do not contain build tools to keep image sizes down.

I also understood it. But why don't use stage build? I always separate build and production images with stage build.

[hsbt]

I'm not sure why aws-sdk-ruby uses bigdecimal for deserialization of DynamoDB.

https://github.com/aws/aws-sdk-ruby/blob/abcd77d379c7cb8a3a988b725ee79b10bfcfd27e/gems/aws-sdk-dynamodbstreams/lib/aws-sdk-dynamodbstreams/attribute_value.rb#L31

In https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.NamingRulesDataTypes.html#HowItWorks.DataTypes, we can use Integer for number type, not BigDecimal. Is there specific reason why we should use it with BigDecimal?

[mullermp]

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.NamingRulesDataTypes.html#HowItWorks.DataTypes

DynamoDB numbers are represented as strings and can have 38 digits of precision, which could be a loss of precision if using Integer.

[SamSaffron]

Another issue here @hsbt

I discovered this today on https://github.com/discourse/mini_sql

Getting the dependency right in a gemfile is a bit of nightmare. I want to depend on bigdecimal but only on version 3.4. How can we do that?

[hsbt]

How can we do that?

I recommend to add bigdecimal to mini_sql dependency simply.

[SamSaffron]

not ideal, it is a binary dependency so I am forcing people an extra compile step on 3.3 and below

[tompng]

I think the original question is answered:

• BigDecimal is a bundled gem, installed as default. Can be used without installing.
• Pre-built binary is not planned

Specifying different version in Gemfile/Gemfile.lock requires installation, but this is also true for other native extension bundled gems. There's an option to edit Gemfile/Gemfile.lock and remove version lock or lock to bundled version.

If bigdecimal is listed as a dependency by any of the gems in a users Gemfile a bundle install will fail if they cannot build and install native extensions

I want to depend on bigdecimal but only on version 3.4

If someone want a way to avoid bundler locked version problem, I think it's better to discuss in https://github.com/ruby/rubygems since this issue is not restricted to bigdecimal, and there is nothing we can do in bigdecimal side.