Is It a Bad Practice to List Ruby Version in Both Gemfile and .Ruby-Version Dotfile

Is It A Bad Practice to List Ruby Version in Both Gemfile and .ruby-version Dotfile?

They were each developed by different teams at different times, and are used by different software.

Listing a ruby version in the Gemfile is a feature in bundler.

As the Gemfile is mostly only used by bundler, it will mainly only effect things when you run the with bundler -- using bundle exec, or software (like Rails) that automatically triggers bundler for you. It's effect is simply to error out and refuse to run if you aren't using the version of ruby specified. It's a requirement -- run under this ruby, or I'll throw an error warning you you're running under the wrong ruby.

However, heroku also pays attention to the version specified in the Gemfile, and will run under that version. Heroku decided to use the feature in bundler too. But most other software, on your workstation, or even travis, does not use that convention. (Travis makes you edit your .travis.yml ENV to specify ruby version to use).

The feature in bundler was introduced in Bundler 1.2 in August 2012.

The .ruby-version file was first introduced by rvm, the first ruby version manager. If you are using rvm, and you switch into a project direcotry with a .ruby-version file, rvm will automatically switch your shell to using the ruby version specified.

I'm not sure when rvm introduced this feature, but I think before the Gemfile "ruby" feature.

Since rvm introduced it, other ruby version switching software like rbenv and chruby have adopted it too to do the same thing -- automatically switch to the ruby version specified when you cd into the directory. Although I think with rbenv and chruby both it may be an optional feature.

So they were different features introduced into and supported by different software packages at different times, doing somewhat different things.

I agree it would be annoying to maintain both, and keep them in sync.

They are both actually optional, you don't need to use either one. Except that you might need to use the Gemfile ruby spec for heroku, to tell it which ruby you want it to run.

I don't personally use either. But if you need to work in different ruby versions in different projects, and find it convenient to have your ruby version manager (rvm, rbenv, or chruby) automatically switch to the right project-specific ruby version, .ruby-version might be useful.

Except for heroku purposes, listing ruby in the Gemfile is mostly just to keep yourself from making a mistake, for instance on deployment. Or perhaps an in-house automated deployment or CI environment could use them somewhat like heroku does, or perhaps other cloud deployment stacks will or have adopted it. I think many have found it not too useful though -- this one too, I wouldn't use until you run into or see a problem that it's solving. One inconvenience some people have with listing ruby versions in Gemfile is that with new rubies always coming out, you've got to be updating all your Gemfiles all the time.

In general, the last couple years of ruby releases have all been very backwards compatible, limiting the need to be sure you're using an exact version of ruby, most recent code will run on the most recent ruby, even if it was originally written for an older one.

I don't believe either feature lets you specify a range of ruby versions, like 2.2.* or what have you.

With either/both features, use them only if you need them or find them useful, you don't have to use either, and it's fine (if annoying) to use both, if you need what both do.

Since a Gemfile is live ruby code, you could theoretically have your Gemfile read your .ruby-version file and automatically use that value as the Gemfile ruby value. If you wanted to use both, and "don't repeat yourself" with it. I don't know if that's a common thing to do, I just thought of it. But it should work fine.

Is it a Bad Practice to Have Both a .rvmrc and a .ruby-version in a Ruby Project?

It is a "bad practice" in that it maintains two conventions at once, which can lead to version management issues in some environments. It also makes it possible for one of the conventions to fall out of sync with the other in regards to the version of ruby used in the project. The .ruby-version file is more conventional at this time, so it would be best to remove the .rvmrc file and only maintain .ruby-version.

how update Rails ruby minor version

The specifier ~> has a special meaning, best shown by example. ~> 3.0 is identical to >= 3.0 and < 3.1. So all minor patches are included. See https://bundler.io/gemfile.html.

No need to change your Gemfile just install the gems in the newly installed Ruby version.

Only one version of Ruby works when multiple versions are installed

I had the exact same issue, except using rbenv with bash.

The perpetrator seems to be the echo "export RUBYOPT='-W:no-deprecated -W:no-experimental'" line in your .zsh file, I'm not sure if Ruby 2.6.5 understands it.

Remove echo "export RUBYOPT='-W:no-deprecated -W:no-experimental'" from your .zsh / .bashrc / .profile and restart your shell.

How to fix Unknown ruby interpreter version (do not know how to handle): RUBY_VERSION.

Coincidentally today I am also trying to setup Jekyll and am seeing the same problem. I am using RVM and it otherwise works fine (running multiple Rails dev sites locally). When I run env | grep 'RUBY' I get:

$ env | grep 'RUBY'
MY_RUBY_HOME=/Users/myusername/.rvm/rubies/ruby-2.0.0-p247
RUBY_VERSION=ruby-2.0.0-p247

However, I just continued and ran bundle install, then bundle exec jekyll serve and the site booted up without issue.

Determining the gem's list of files for the specification

With Rake

The easiest solution depending on rake to list all files from a directory, but exclude everything in the .gitignore file:

require 'rake/file_list'
Rake::FileList['**/*'].exclude(*File.read('.gitignore').split)

RubyGems

Official rubygems solution, list and exclude manually:

require 'rake'
spec.files = FileList['lib/*.rb',
                      'bin/*',
                      '[A-Z]*',
                      'test/*'].to_a

# or without Rake...
spec.files = Dir['lib/*.rb'] + Dir['bin/*']
spec.files += Dir['[A-Z]*'] + Dir['test/**/*']
spec.files.reject! { |fn| fn.include? "CVS" }

Bundler

Bundler solution, list manually:

s.files = Dir.glob("{lib,exe}/**/*", File::FNM_DOTMATCH).reject {|f| File.directory?(f) }

Note: rejecting directories is useless as gem will ignore them by default.

Vagrant

Vagrant solution to mimic git ls-files and taking care of .gitignore in pure ruby:

  # The following block of code determines the files that should be included
  # in the gem. It does this by reading all the files in the directory where
  # this gemspec is, and parsing out the ignored files from the gitignore.
  # Note that the entire gitignore(5) syntax is not supported, specifically
  # the "!" syntax, but it should mostly work correctly.
  root_path      = File.dirname(__FILE__)
  all_files      = Dir.chdir(root_path) { Dir.glob("**/{*,.*}") }
  all_files.reject! { |file| [".", ".."].include?(File.basename(file)) }
  all_files.reject! { |file| file.start_with?("website/") }
  all_files.reject! { |file| file.start_with?("test/") }
  gitignore_path = File.join(root_path, ".gitignore")
  gitignore      = File.readlines(gitignore_path)
  gitignore.map!    { |line| line.chomp.strip }
  gitignore.reject! { |line| line.empty? || line =~ /^(#|!)/ }

  unignored_files = all_files.reject do |file|
    # Ignore any directories, the gemspec only cares about files
    next true if File.directory?(file)

    # Ignore any paths that match anything in the gitignore. We do
    # two tests here:
    #
    #   - First, test to see if the entire path matches the gitignore.
    #   - Second, match if the basename does, this makes it so that things
    #     like '.DS_Store' will match sub-directories too (same behavior
    #     as git).
    #
    gitignore.any? do |ignore|
      File.fnmatch(ignore, file, File::FNM_PATHNAME) ||
        File.fnmatch(ignore, File.basename(file), File::FNM_PATHNAME)
    end
  end

Pathspec

Using pathspec gem Match Path Specifications, such as .gitignore, in Ruby!

See https://github.com/highb/pathspec-ruby

References

Ref:
Bundler
Vagrant
RubyGems
Rake easy solution

---

Related Topics