Update `gem` and `bundler`?

[jaredbeck]

Before running bundle outdated, it's desirable to have the latest gem and bundler.

gem update --system
bundle update --bundler
# commit -m "bundler x (was y)"

Should this be automatic? If so, should there be a CLI option to disable it?

[shanecav84]

bunup operates in the context of a Gemfile, so this would step out of those bounds. Not against the idea though, we do a similar thing in libyear where we also check for the Ruby version (maybe we should check the gem and bundler versions there as well).

Given that this change would be out the bounds of a Gemfile, we could either/or add flags to enable/disable, and also add a confirmation step like we do with major release semver updates.

[jaredbeck]

Thanks for the quick feedback!

My motivation here is that bunup depends on bundle outdated to be correct. Some recent bundler versions have bugs in outdated, like ruby/rubygems#4451.

So, at a minimum, I think a warning is warranted, but I think it'd be convenient to automatically update gem and bundler. For experts who must use old versions, we could have CLI options like --no-update-rubygems, and --no-update-bundler. I'd suggest we avoid interactive prompts, so that bunup can be used from non-interactive scripts.

[shanecav84]

That all sounds good. I think the interactive prompt should be the default because the primary use case is updating a project's dependencies which should require some interactivity for some semver updates. We do have the -y --yes --assume-yes for bypassing the prompts.

I can look into adding this soon. I've been meaning to give the bunup a good once-over.

[jaredbeck]

We do have the -y --yes --assume-yes for bypassing the prompts.

Oh right, there's a prompt about major-version updates, isn't there? I forgot about that.

We'd phrase the prompt so that --yes would automatically update gem and bundler?

I can look into adding this soon.

It's not urgent, just a random thought I had, but if it interests you, go for it.