Ruby 3.4 and BigDecimal. about bigdecimal HOT 7 OPEN

@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?

from bigdecimal.

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.

from bigdecimal.

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.

from bigdecimal.

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.

from bigdecimal.

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.

from bigdecimal.

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?

from bigdecimal.

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.

from bigdecimal.