0

After running various commands (bundle and rspec for example) in a Ruby project, Gemfile.lock is updated and x86_64-darwin-17 is added to the PLATFORMS heading. Why is this happening? How can I prevent it?

Running gem env gives this interesting context:

○ → gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 2.7.6
  - RUBY VERSION: 2.5.1 (2018-03-29 patchlevel 57) [x86_64-darwin17]
  #...etc  
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-darwin-17
RangerRanger
  • 2,455
  • 2
  • 16
  • 36
  • Why do you want to prevent it? `Gemfile.lock` is designed to make your gem environment reproducible. If it's being updated it just means that you're running with a different environment than you were previously e.g. if one of your gems was updated to have a new dependency. – Max Jun 08 '18 at 17:51
  • It's a project that I've recently joined with multiple other contributors. Their system info isn't listed there. I've got the correct ruby and bundler version so I don't want to check this change into git. – RangerRanger Jun 08 '18 at 18:06
  • This happens to me all the time, and I just try not to commit them. Not a great solution, but I'm in the habit of always checking my changes before I commit or push so it hasn't be a problem. – Max Jun 08 '18 at 18:14
  • What is your issue exactly? if you run `bundle`, then the gems specified in your `Gemfile` will be installed, and the versions of all these gems will be specified your `Gemfile.lock`. Running rspec shouldn't affect the state of your bundle. – Caleb Keene Jun 09 '18 at 20:53
  • 1
    I added an answer. There was a global bundler config which was responsible for the behavior. Whether or not running rspec is supposed to touch the lockfile, it was updating it unexpectedly. – RangerRanger Jun 10 '18 at 18:13

3 Answers3

4

The answer from @RangerRanger didn't work for me but I checked in the bundler doc as he did and find this who worked for me:

force_ruby_platform (BUNDLE_FORCE_RUBY_PLATFORM): Ignore the current machine's platform and install only ruby platform gems. As a result, gems with native extensions will be compiled from source.

Here is the command: bundle config force_ruby_platform true

BTL
  • 4,311
  • 3
  • 24
  • 29
3

This was caused by global bundler config. Setting to false stopped the behavior.

specific_platform (BUNDLE_SPECIFIC_PLATFORM): Allow bundler to resolve for the specific running platform and store it in the lockfile, instead of only using a generic platform. A specific platform is the exact platform triple reported by Gem::Platform.local, such as x86_64-darwin-16 or universal-java-1.8. On the other hand, generic platforms are those such as ruby, mswin, or java. In this example, x86_64-darwin-16 would map to ruby and universal-java-1.8 to java.

RangerRanger
  • 2,455
  • 2
  • 16
  • 36
1

If you want to install dependencies without updating the Gemfile.lock, just use the --frozen option. e.g. bundle --frozen. This will install dependencies normally, except not update the Gemfile.lock

Edit

If this is not a good solution, probably the best bet is going to be adding the Gemfile.lock to a .gitignore specific to your local repo. You can create one at your_repo/.git/info/exclude as per this answer

iCodeSometime
  • 1,444
  • 15
  • 30
  • I appreciate the idea but this occurs in more cases than running bundle. For instance, the line is added after running rspec tests. – RangerRanger Jun 08 '18 at 19:17
  • .gitignore is probably what you're looking for then. you can have one specific to only your local repo. – iCodeSometime Jun 08 '18 at 19:26
  • As far as I can tell `bundle exec rspec` shouldn't update the gemfile.lock. I've never seen that happen to me.. Another possible solution is to alias `bundle` -> `bundle --frozen` – iCodeSometime Jun 08 '18 at 19:45