Open mullermp opened 7 months ago
@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?
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.
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.
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.
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.
I'm not sure why aws-sdk-ruby
uses bigdecimal
for deserialization of DynamoDB.
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
?
DynamoDB numbers are represented as strings and can have 38 digits of precision, which could be a loss of precision if using Integer.
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?
How can we do that?
I recommend to add bigdecimal
to mini_sql
dependency simply.
not ideal, it is a binary dependency so I am forcing people an extra compile step on 3.3 and below
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?