9

I had two versions of bundler installed locally 1.15.2 and 1.16.1. I had pushed my code and soon realized that the gemfile.lock BUNDLED WITH, updated the version to 1.16.1 and that is not what we want.

I then removed 1.16.1 locally and now my default is 1.15.2 which is exactly what I want and ran bundle install in the checked out branch hoping that it would update ( downgrade ) the BUNLED WITH to 1.15.2 but git diff and searching the gemfile.lock shows that nothing has changed and it still says 1.16.1.

Should I go in and manually change it which I know is never a good idea to manually edit the Gemfile.lock. Or is there a command to run that will do what I intend it to do.

Thanks

Chris
  • 367
  • 4
  • 16
  • 1
    Firstly, the "bundled with" doesn't really matter. Secondly, you could just change it manually. And lastly, I'm order to change it "automatically" you'll need to trigger some event that actually regenerates the file - for example, downgrade a gem then update it again. (But this is quite a pointless exercise since you could also have just edited the Gemfile.lock manually, or even ignored this bundler version discrepancy in the first place.) – Tom Lord Sep 26 '18 at 04:08
  • 1
    However, I must ask - why did you intentionally downgrade bundler? I don't recall a single instance where I've needed to do that, for any reason. – Tom Lord Sep 26 '18 at 04:09
  • I've had problems with Heroku using Bundler 2.x – a2f0 Jun 18 '19 at 14:35
  • I have had to downgrade bundler. We have a specific version of bundler on production, both for heroku apps and apps on FreeBSD driven by what FreeBSD packages are available. We want our dev environment to match production, so when a developer bundles with a later version than prod we want to downversion. – Marlin Pierce Feb 09 '21 at 13:27

3 Answers3

9

bundle update --bundler will update the BUNDLED_WITH version.

Jared
  • 2,885
  • 2
  • 28
  • 31
4

Did you try with bundle update?.

If this doesn't work go to your Gemfile.lock and change it manually.

Or delete the line and then do bundle install /update----add the gem and then do bundle install/update again.

Hope it helps

1

Process: install the gem generically, looking up your target version on rubygems.org, then update and version your Gemfile.

the install command is in the right-hand column. then you can:

gem install gem_name -v 1.5.4 and see what results of dependencies et al. respecify the gem version in your gemfile (the lock file is not meant to be edited). Then bundle install for your app to be secure.

AATHITH RAJENDRAN
  • 4,689
  • 8
  • 34
  • 58
Jerome
  • 5,583
  • 3
  • 33
  • 76
  • Thanks for the explanation, even still confuse why we locked in this kind of problem. – Adi Prasetyo May 01 '21 at 17:34
  • You may be looking at the wrong problem. The point is you *want* to version your Gemfile, specifically for dependency issues. When you need to move to a new ruby or rails version, you can incrementally adjust your versions. Try migrating a 4.1 rails to 6.1 with no Gemfile versioning: the problem is exponential. – Jerome May 02 '21 at 06:24
  • is it applied to general versioning, like npm or composer? I am not trying to be ruby developer tho. – Adi Prasetyo May 02 '21 at 16:23
  • I wouldn't have a good notion of 'general versioning'; but you decide to use and depend on a gem, that was (probably) written with its own dependencies. The rails environment makes these dependencies 'evident' by generating a Gemfile.lock that documents these. – Jerome May 02 '21 at 17:44
  • Pls stop making me want to say thank you, general versioning -> publishing a module, a mini-software, a microservice, a file with a bunch of functions, aa whateveritcanbecalled. I notice .lock is popular on github at the same time. – Adi Prasetyo May 02 '21 at 18:48