Bug #13978: Remove Bundler from StdLib

• Status: Rejected
• Assignee: -
• Target version: -
• ruby -v: ruby 2.5.0dev (2017-10-03 trunk 60107) [x86_64-linux]
• Backport: 2.3: UNKNOWN, 2.4: UNKNOWN

[vo.x (Vit Ondruch)]

While I acknowledge people are using Bundler and it provides valuable services, I hate to point out that Bundler was merged to the StdLib on the grounds of "rubygems team has plan to migrate bundler into rubygems at rubygems 3.0." 1, but I can't see this plan to materialize.

Bundler was merged directly into StdLib on the grounds of "Rubygems itself is going to depend on bundler." but that is nowhere close IMO. Looking at diff between RubyGems 2.6 and master 2, there is nothing more then one condition. That does not look as an integration.

If the Bundler is going to be used by RubyGems (and actually it should be the other way around, Bundler should depend on RubyGems and not the way around), then would propagate into Ruby naturally as part of RubyGems.

And there is serious bundling going around. Why StdLib ships now with two copies of bundled Mollinilo. Why there are even two copies of "filesystem" library now? Why there is bundled Thor and Bundler and RubyGems are using different approach of handling CLI?

This was very premature step IMO and I'd like to see it reverted. If Bundler should be part of Ruby ATM, then it should currently shipped as default gem and not anything else.

[hsbt (Hiroshi SHIBATA)]

• Status changed from Open to Rejected

Bundler was merged directly into StdLib on the grounds of "Rubygems itself is going to depend on bundler." but that is nowhere close IMO. Looking at diff between RubyGems 2.6 and master 2, there is nothing more then one condition. That does not look as an integration.

Rubygems master targeted version 2.7.0 already depends on bundler. see https://github.com/rubygems/rubygems/blob/master/lib/rubygems/test_case.rb#L28
Therefore We should bundle bundler for upgrading bundled RubyGems.

And there is serious bundling going around. Why StdLib ships now with two copies of bundled Mollinilo. Why there are even two copies of "filesystem" library now? Why there is bundled Thor and Bundler and RubyGems are using different approach of handling CLI?

It's an upstream issue, not ruby core. but I've same concerns for duplicate libraries like Mollinilo. I try to diet these files before releasing Ruby 2.5.

[vo.x (Vit Ondruch)]

hsbt (Hiroshi SHIBATA) wrote:

Bundler was merged directly into StdLib on the grounds of "Rubygems itself is going to depend on bundler." but that is nowhere close IMO. Looking at diff between RubyGems 2.6 and master 2, there is nothing more then one condition. That does not look as an integration.

Rubygems master targeted version 2.7.0 already depends on bundler. see https://github.com/rubygems/rubygems/blob/master/lib/rubygems/test_case.rb#L28
Therefore We should bundle bundler for upgrading bundled RubyGems.

I saw this require, but you are referring to test dependency which should be no concern IMO.

And there is serious bundling going around. Why StdLib ships now with two copies of bundled Mollinilo. Why there are even two copies of "filesystem" library now? Why there is bundled Thor and Bundler and RubyGems are using different approach of handling CLI?

It's an upstream issue, not ruby core. but I've same concerns for duplicate libraries like Mollinilo. I try to diet these files before releasing Ruby 2.5.

Once ruby-core starts do depend on such code (and this was voluntary decision), then it should be ruby-core concern as well.