Configuration option to disable BUNDLED WITH?

[bronson]

Hi, I'm getting tired of having to manually remove the BUNDLED WITH from my lock files. It's easy to forget and accidentally commit it. And, for obvious reasons, I don't want to force everyone on my team to update the version of bundler that they're using.

Any chance of adding a configuration option to suppress BUNDLED WITH? That way we can all be happy?

This is related to rubygems/bundler#3697 of course. Bundler's current behavior is somewhat difficult to live with. Thank you!

[vasilakisfil]

yeah me too I don't understand why they added that :/

[indirect]

I believe that the underlying issue with BUNDLED WITH is resolved by rubygems/bundler#3722.

[bronson]

No, I don't think rubygems/bundler#3722 resolves the problem:

$ bundle _1.10.3_ install
$ git status
modified:   Gemfile.lock     (now contains BUNDLED WITH clause)
$ bundler _1.9.8_ install
$ git status
(BUNDLED WITH clause has been deleted from Gemfile.lock)

My commits will keep adding BUNDLED WITH, and my teammates' commits will keep removing it. The git churn still exists.

[andremedeiros]

Guys, this is easily resolved by gem update bundler. Is there any reason why your teammates are running an older version?

[bronson]

I have no control over their machines.

Given the time this has removed from my day so far, I completely understand why anyone would be reluctant to upgrade! I think I'll be more careful myself in the future.

[andremedeiros]

This is a one-off where we're asking everyone to get on board.

If everyone is on >= 1.10.0, the Gemfile.lock will only be updated to reflect the newest Bundler version that has ever parsed that Gemfile.lock, and if you really REALLY want to disable that, you can always hardcode that version to 99.0.0 and live without the warning.

[bronson]

Mandating everyone to upgrade to 1.10+ just doesn't seem like acceptable behavior for a mature project. Especially for a point release.

"If everyone is on >= 1.10.0..."

How long do you suppose that will take?

[segiddins]

you can mandate it by doing raise 'run 'gem install bundler' unless Bundler::VERSION >= '1.10.0' in your gem file, if you so wish

[indirect]

How long do you suppose that will take?

Well, 96% of active Bundler users this week were running a release less than a year old. 30% upgraded within 60 days, 30% within 6 months, and the remaining 30% within 12. I'm guessing that 1.10 will follow a similar trajectory, although it's definitely possible it'll be faster now that people have a reason to upgrade.

I've been asking people to upgrade, after explaining that this change is to protect applications that need specific features and to lay the groundwork for Bundler 2.0, and most people have just said "oh, that makes sense. I'll ask the rest of my team to update Bundler, thanks." You say that you're not willing to ask other devs to upgrade their copy of Bundler for "obvious reasons". What are those obvious reasons?

[bronson]

No, I definitely do not want to mandate it. We have our hands full with a large project and tight deadlines. Why would I want to move everyone to an unstable version of Bundler too? I'm not even project lead.

If I tell anybody anything, I'd recommend staying on 1.9 for now.

I still don't quite understand why you're doing this experiment on a point release?

[segiddins]

This is not an experiment. Bundler releases updates that, in addition to adding new features, can often fix critical bugs. Adding the Bundler version to the lockfile has been on our wishlist for years, so we can help teams ensure they're using the same version of bundler, and thus seeing the same ruby environment in their applications, across different members of the team. Just as you'd never let different team members use different rails versions in development from each other, you should be using the same, known-good versions of bundler. This change in Bundler 1.10 makes that possible.

[bronson]

Since it sounds like the Bundler team was surprised to hear about the lockfile churn, it feels a little like a release-mode experiment, doesn't it? Nobody used the new version in a team environment?

Here is my position: if I tell everyone to move to 1.10, and then they lose time to bugs/misfeatures/whatever, that's MY fault. I let the team down. I don't feel very confident in 1.10 right now, and I don't have time to vet it... I'm stuck.

I get the message, it sounds like the Bundler team wants this new feature above all else. No problem, I'll downgrade to 1.9, tell everyone to double-check Gemfile.lock for the next year, and I'll be more careful about upgrading Bundler in the future.

Thanks for Bundler, it really is critical infrastructure.

[segiddins]

@bronson no, 1.10.0 has several pre releases and RCs before being released, and in that time we heard literally 0 complaints about this change. You can have your team do whatever you want, but this change is a critical step for us being able to confidently release Bundler 2.0 without a barrage of people wondering why things aren't working.

[bronson]

Since you already got a barrage of people wondering during the 1.9->1.10 transition, 2.0 should go super smooth. :)

[parkr]

This has annoyed the heck out of my team, most of whom aren't Ruby people. We guard against uncommitted changes on deploy and if the bundler version differs even by a PATCH level, everything breaks. Annoyances like this feel like breaking changes to our team, no matter how you version it.

Pre-releases aren't a good way to get representative feedback. I have learned this the hard way with Jekyll.

/cc rubygems/bundler#3726 rubygems/bundler#3706 rubygems/bundler#3720 rubygems/bundler#3623 rubygems/bundler#3719 rubygems/bundler#3697

[indirect]

@parkr bundle exec cap deploy does not change the lock. Rather than telling us that "everything breaks" so that means we're Doing It Wrong™, why don't you write up an actual description of your workflow, the commands you run, the versions of Bundler you're using, and the problems it's causing you? I haven't had any takers yet.

[parkr]

Hey, @indirect! Thanks for the response. It doesn't bother me so much because I can just commit the change and continue on, but others were frustrated. Just sharing the upgrade path using our workflow. We do this to deploy:

1. git checkout master
2. git pull origin master (grab the latest production code)
3. bundle install (make sure we can successfully run bundle exec)
4. bundle exec cap production deploy

We are using cap_git_tools to guard against uncommitted changes. Upon execution of step 3, the BUNDLED WITH shows up. If my Bundler version is different than someone else's, then step 4 shows a "warning! uncommitted changes!" error and fails. If it only happened on MINOR versions of Bundler (i.e. 1.10 vs 1.11) then it'd be easier. But bundler versions on my team's machines range from 1.9.9 to 1.10.3 so we run into this a lot.

To get around it for now, we do bundle install && git checkout Gemfile.lock while we work to make sure everyone is on the same version. Synchronizing upgrades will be annoying, though, so I'm weary of that.

[indirect]

I'm sorry to hear that your team is having trouble. I think that this will turn out to be less of a problem in the long run than it is right now, and you can leave all (or at least almost all) of the pain behind you by asking your team to upgrade to Bundler 1.10.

Starting with 1.10, Bundler will only modify the lock to increment the version number—existing versions will not be removed. Once everyone on your team is running Bundler 1.10, the lock will only change when the running version of Bundler is greater than the version saved in the lock. At that point, committing the lock, pushing, and then deploying is exactly the desired behavior. Older versions of Bundler (that are 1.10 or higher) simply will not change the lock at all.

If you need to run multiple versions of Bundler in different projects, you could try the postit gem, which automatically activates the version of Bundler indicated by the lock file when you run postit exec.

[parkr]

Ok, thanks @indirect!

[bronson]

you can leave all (or at least almost all) of the pain behind you by asking your team to upgrade to Bundler 1.10

Should this go in the README?

[maxlazio]

How do I approach 1000 contributors on an open source project to use the same version of bundler?
This might come off as rude on second read(I am not a native speaker) so wanted to explain a bit:
I am a team member of a large open source project and we have several hundred contributors. We've started running into this issue recently when our Gemfile.lock got updated and now every other contribution has merge conflicts due to contributors not having the same version.
The recommendation of using postit is not applicable to us and obviously it is nearly impossible to ask large number of contributors to upgrade their bundlers.
Do you have any recommendations on how to approach this situation?

[dzaporozhets]

I wrote a stupid comments and removed it in 5 minutes when I re-read it. Sorry guys. Bundler is awesome and I will try to be constructive.

[indirect]

@maxlazio The Bundler documentation already includes a blanket solution for merge conflicts in the lock file, because they are very common. If that solution (which is git checkout HEAD -- Gemfile.lock && bundle install && git add Gemfile.lock) does not work for you for some reason, can you describe the conflicts that you're seeing, so we can try to come up with a better solution?

[indirect]

We won't be adding an option to disable BUNDLED WITH, but we've released 1.9.10, updated to completely ignore the BUNDLED WITH section. We've also added workarounds for BUNDLED WITH issues in 1.10.4 and 1.10.5, and the BUNDLED WITH section will no longer be added or updated during bundle install if there are no other changes to the lock. (Anyone who explicitly wants to update the BUNDLED WITH section can run bundle update --source bundler --local.) Read more about it on the Bundler blog.

[dzaporozhets]

BUNDLED WITH section will no longer be added or updated during bundle install if there are no other changes to the lock

awesome. Thank you

[dbwest]

I'm using Bundler version 1.12.5 and it still puts the BUNDLED WITH section in.

How can I stop it from doing that. From looking at these posts it looks like that 'feature' was supposed to have been removed some versions back anyway...

[chrismo]

@dbwest The message from indirect earlier in this discussion includes the phrase, "if there are no other changes to the lock" ... BUNDLED WITH will still appear in the lockfile, it just shouldn't be written if there's no other changes. That may be the bit you're missing?

[dbwest]

@chrismo I saw that. There were no other changes in the lockfile.