15

Every time I run any gem command on the command line, Bundler insists on touching my Gemfile.lock file to add this line:

RUBY VERSION
   ruby 2.2.2p95

I don't want to commit this to our repository, because it means every dev using a different patch level of Ruby 2.2.2 is going to be in a commit war with me. (I've already resigned myself to a similar issue with the BUNDLED_WITH line.) But I can't deploy unless I do commit that line, because our deploy runs via a rake task and running the deploy leads Bundler to add this block, whereupon the deploy process says, "WAIT! Your working tree is dirty! You might be deploying incomplete changes!!!!1!" (Well, not literally, but you get the idea.)

Can I tell Bundler to leave the RUBY VERSION (and, ideally, BUNDLED_WITH) out of the Gemfile.lock so we don't have to do this ridiculous dance?

(how to prevent bundler from adding platform info to Gemfile.lock seems to be the same question, but there's no answer, natch.)

Community
  • 1
  • 1
pjmorse
  • 9,204
  • 9
  • 54
  • 124

3 Answers3

9

I don't think so, but maybe it's okay:

As of 2.1.0, Ruby no longer has multiple patch level releases for a given version. See accepted answer on How do version numbers work for MRI Ruby?

2.2.2p95 is the only patch level of 2.2.2 that will ever be released. 'p95' just means that there have been 95 commits since 2.2.0.

Since your whole team will be on 2.2.2 anyway, it shouldn't cause problems to leave this in your Gemfile.lock. (As long as everyone updates Bundler to the version that does this, anyway. Otherwise there'll still be conflicts as the ruby version is added and removed.)

Community
  • 1
  • 1
MrTheWalrus
  • 9,670
  • 2
  • 42
  • 66
  • 3
    And yet it turns out we get commit wars anyway, not over the Ruby version but over different versions of Bundler adding and removing this block. *sigh* – pjmorse Apr 01 '16 at 15:18
  • @pjmorse I think it is good for all the team members to have the same Bundler version. If you need to lock the gems, why not Bundler? – Franklin Yu Aug 23 '16 at 03:46
  • @FranklinYu good question. I think because Bundler is developer tooling and not a direct dependency of the application, locking its version is less important than locking gem versions. (Also, if your team is working on multiple applications, you'll need to coordinate the locked version of Bundler across the applications, which can be a drag. You're essentially committing your team to lockstep Bundler updates.) – pjmorse Aug 24 '16 at 15:33
  • @pjmorse I didn't actually encounter any problem for multiple application, since old Bundler can totally parse a `Gemfile.lock` generated by a new Bundler. It is actually not *locking*, but instead to notify other team members about a new release of Bundler. It does not force anyone to upgrade, just tells them "you are not using the latest version in your team". If no member or machine joins the team, it will stay at that version. – Franklin Yu Aug 24 '16 at 21:34
  • @pjmorse In fact, I did see [someone else encounters problems](https://github.com/bundler/bundler-features/issues/88), but the Bundler team doesn't seem to regret this decision. Normally my team would prefer not to go against the gem developers, to make our lives easier. – Franklin Yu Aug 24 '16 at 21:37
1

No, it can't be removed, at least in the version(s) of Bundler current as I write this.

This block is added in the #to_lock method of Bundler::Definition. The only conditional it's wrapped in is if locked_ruby_version, and locked_ruby_version is a method which returns either the version defined in an existing lockfile (Gemfile.lock) or the system Ruby - Bundler tries very hard to avoid letting locked_ruby_version return a falsy value.

pjmorse
  • 9,204
  • 9
  • 54
  • 124
-4

If you are using some sort of version control like Git you can add the Gemfile.lock to your .gitignore file.

This way anytime you push up a new change you will not push up your Gemfile.lock. Especially since other developers do not need it - once they run bundle, bundle will create a new Gemfile.lock on completion.

jdave
  • 845
  • 2
  • 11
  • 27
  • 6
    The whole point of Gemfile.lock is to lock down the exact dependency versions based on the requirements specified in Gemfile. Committing Gemfile.lock is pretty much required if you want a reproducible environment. – jackrabbit Mar 30 '16 at 20:48
  • 2
    Leaving the `Gemfile.lock` out of the git repository is not an option. We *do*, in fact, want all the developers on our team using the same versions of all the gems in the project. – pjmorse Mar 31 '16 at 12:57