Bug #13978
closed
Remove Bundler from StdLib
Description
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.
Updated by hsbt (Hiroshi SHIBATA) about 7 years ago
- 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.
Updated by vo.x (Vit Ondruch) about 7 years ago
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.