Skip to content

Conversation

skipkayhil
Copy link
Member

@skipkayhil skipkayhil commented Sep 23, 2023

Motivation / Background

Fixes #51014
Fixes #51089

Previously, new apps would have a Ruby version set in both the Gemfile and the .ruby-version file. This duplication makes it more difficult to quickly change an application's ruby version as users must remember to update multiple files.

Detail

This commit updates the app generator's Gemfile to read the Ruby version from the .ruby-version file. Since this feature was introduced in the latest version of Bundler, it will only be enabled if a supported version of Bundler is used.

Additional information

Alternatively, another solution mentioned on the original PR adding .ruby-version was that the .ruby-version file could be removed once rvm/rbenv support reading the Ruby version from the Gemfile. This has a downside that many other tools like chruby do not have plans to support reading a Ruby version from the Gemfile, and so users of those tools would have a worse experience if the .ruby-version file is removed.

Checklist

Before submitting the PR make sure the following are checked:

  • This Pull Request is related to one change. Changes that are unrelated should be opened in separate PRs.
  • Commit message has a detailed description of what changed and why. If this PR fixes a related issue include it in the commit message. Ex: [Fix #issue-number]
  • Tests are added or updated if you fix a bug or add a feature.
  • CHANGELOG files are updated for the changed libraries if there is a behavior change or additional feature. Minor bug fixes and documentation changes should not be included.

@rails-bot rails-bot bot added the railties label Sep 23, 2023
@skipkayhil
Copy link
Member Author

Drafted because rubygems/rubygems#6985 hasn't quite been released yet

@sinsoku
Copy link
Contributor

sinsoku commented Sep 24, 2023

@skipkayhil
bundle install requires .ruby-version, so you should modify the Dockerfile as well.
I think you should modify the following parts.

# Install application gems
COPY Gemfile Gemfile.lock ./
RUN bundle install && \
rm -rf ~/.bundle/ "${BUNDLE_PATH}"/ruby/*/cache "${BUNDLE_PATH}"/ruby/*/bundler/gems/*/.git<% if depend_on_bootsnap? -%> && \
bundle exec bootsnap precompile --gemfile<% end %>

@simi
Copy link
Contributor

simi commented Sep 24, 2023

@skipkayhil bundle install requires .ruby-version, so you should modify the Dockerfile as well. I think you should modify the following parts.

# Install application gems
COPY Gemfile Gemfile.lock ./
RUN bundle install && \
rm -rf ~/.bundle/ "${BUNDLE_PATH}"/ruby/*/cache "${BUNDLE_PATH}"/ruby/*/bundler/gems/*/.git<% if depend_on_bootsnap? -%> && \
bundle exec bootsnap precompile --gemfile<% end %>

Indeed this is one of the caveats of .ruby-version support in Bundler. It should be copied next to Gemfile to production container even it's original purpose is mostly for development. 🤷

@dhh
Copy link
Member

dhh commented Jan 1, 2024

Did you find a way to address the Dockerfile as well?

@skipkayhil
Copy link
Member Author

skipkayhil commented Jan 1, 2024

Yes I was wrapping it up yesterday, let me push it up

Edit: unless you mean can the Dockerfile also read the .ruby-version for the image version, in which case I have not addressed that

@dhh
Copy link
Member

dhh commented Jan 1, 2024

Also, do we need the version split if Ruby 3.1+ is now required?

@skipkayhil skipkayhil force-pushed the hm-gemfile-ruby-file branch from 535d876 to 6cbdc3f Compare January 1, 2024 18:22
@skipkayhil
Copy link
Member Author

Also, do we need the version split if Ruby 3.1+ is now required?

We do definitely need the split on using file: since it was added in Bundler 2.4.20 and Ruby 3.1 ships with Bundler 2.3.3

@skipkayhil skipkayhil force-pushed the hm-gemfile-ruby-file branch from 6cbdc3f to bfeb8e3 Compare January 1, 2024 18:40
@dhh
Copy link
Member

dhh commented Jan 1, 2024

Although I wonder if we couldn't just force Bundler 2.4+ with the install of Rails?

@dhh
Copy link
Member

dhh commented Jan 1, 2024

Also, shouldn't "ruby file: ".ruby-version"" just be the default in bundler?

Previously, new apps would have a Ruby version set in both the Gemfile
and the .ruby-version file. This duplication makes it more difficult to
quickly change an application's ruby version as users must remember to
update multiple files.

This commit updates the app generator's Gemfile to read the Ruby version
from the .ruby-version file. Since this feature was introduced in the
latest version of Bundler, it will only be enabled if a supported version
of Bundler is used.

Alternatively, another solution mentioned on the original PR adding
.ruby-version was that the .ruby-version file could be removed once
rvm/rbenv support reading the Ruby version from the Gemfile. This has a
downside that many other tools like chruby do not have plans to support
reading a Ruby version from the Gemfile, and so users of those tools
would have a worse experience if the .ruby-version file is removed.

Co-authored-by: Takumi Shotoku <sinsoku.listy@gmail.com>
@skipkayhil
Copy link
Member Author

@dhh this should be ready to go 👍

@rafaelfranca rafaelfranca merged commit 6985c3b into rails:main Feb 14, 2024
@skipkayhil skipkayhil deleted the hm-gemfile-ruby-file branch February 14, 2024 18:01
rafaelfranca added a commit that referenced this pull request Feb 14, 2024
This reverts commit 6985c3b, reversing
changes made to 3163bb7.

Reason: While we want to apply this change, it make bundle being more
strict about the ruby version. This is particularly problematic for
the devcontainer images that don't support defining which patch
version of ruby to install.

Right now, you can only say you want Ruby 3.2, which could mean
3.2.3 or 3.2.0. If for some reason the devcontainer image doesn't
match the patch version on `.ruby-version` it will fail to install.

We are planning to solve this problem by publishing our own
ruby images that allow defining the patch level, but until that
we can't apply this change.
Ridhwana pushed a commit to Ridhwana/rails that referenced this pull request Mar 7, 2024
…y-file"

This reverts commit 6985c3b, reversing
changes made to 3163bb7.

Reason: While we want to apply this change, it make bundle being more
strict about the ruby version. This is particularly problematic for
the devcontainer images that don't support defining which patch
version of ruby to install.

Right now, you can only say you want Ruby 3.2, which could mean
3.2.3 or 3.2.0. If for some reason the devcontainer image doesn't
match the patch version on `.ruby-version` it will fail to install.

We are planning to solve this problem by publishing our own
ruby images that allow defining the patch level, but until that
we can't apply this change.
viralpraxis pushed a commit to viralpraxis/rails that referenced this pull request Mar 24, 2024
…y-file"

This reverts commit 6985c3b, reversing
changes made to 3163bb7.

Reason: While we want to apply this change, it make bundle being more
strict about the ruby version. This is particularly problematic for
the devcontainer images that don't support defining which patch
version of ruby to install.

Right now, you can only say you want Ruby 3.2, which could mean
3.2.3 or 3.2.0. If for some reason the devcontainer image doesn't
match the patch version on `.ruby-version` it will fail to install.

We are planning to solve this problem by publishing our own
ruby images that allow defining the patch level, but until that
we can't apply this change.
fractaledmind pushed a commit to fractaledmind/rails that referenced this pull request May 13, 2024
…y-file"

This reverts commit 6985c3b, reversing
changes made to 3163bb7.

Reason: While we want to apply this change, it make bundle being more
strict about the ruby version. This is particularly problematic for
the devcontainer images that don't support defining which patch
version of ruby to install.

Right now, you can only say you want Ruby 3.2, which could mean
3.2.3 or 3.2.0. If for some reason the devcontainer image doesn't
match the patch version on `.ruby-version` it will fail to install.

We are planning to solve this problem by publishing our own
ruby images that allow defining the patch level, but until that
we can't apply this change.
yoones pushed a commit to yoones/rails that referenced this pull request Mar 6, 2025
…y-file"

This reverts commit 6985c3b, reversing
changes made to 3163bb7.

Reason: While we want to apply this change, it make bundle being more
strict about the ruby version. This is particularly problematic for
the devcontainer images that don't support defining which patch
version of ruby to install.

Right now, you can only say you want Ruby 3.2, which could mean
3.2.3 or 3.2.0. If for some reason the devcontainer image doesn't
match the patch version on `.ruby-version` it will fail to install.

We are planning to solve this problem by publishing our own
ruby images that allow defining the patch level, but until that
we can't apply this change.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use ruby file: ".ruby-version" when possible Read the Ruby Version in Gemfile Instead of Hardcoding the Version
5 participants