Menu
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.)
743
The version of bundler that's used is the one that's available in your current ruby environment. The best way to manage this is with gemsets - you can create a gemset with a known, working version of bundler and always switch to that gemset when working with that project.
You should always include your Gemfile. lock if you are writing an application. The community seems to (largely) agree that you should include it in any Gems you create as well.
The Gemfile is where you specify which gems you want to use, and lets you specify which versions. The Gemfile. lock file is where Bundler records the exact versions that were installed. This way, when the same library/project is loaded on another machine, running bundle install will look at the Gemfile.
What's the difference? A Gemfile.lock is auto-generated & it says exactly what versions of every gem were installed. Bundler will install these versions so when you deploy this application to production, or share your project with other developers, everyone will be working with an identical set of gems.
Well, it does… but only for the gems themselves. Your regular Ruby application isn’t built as a gem, so it doesn’t get this feature. That’s why Bundler exists!
The Gemfile.lock file is where Bundler records the exact versions that were installed. This way, when the same library/project is loaded on another machine, running bundle install will look at the Gemfile.lock and install the exact same versions, rather than just using the Gemfile and installing the most recent versions.
A Gemfile is a file we create which is used for describing gem dependencies for Ruby programs. A gem is a collection of Ruby code that we can extract into a “collection” which we can call later. It lets you specify which gems you want to use, and which versions of these gems to use.
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.)
95
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.
42
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
