[ruby-core:83123] [Ruby trunk Bug#13978] Remove Bundler from StdLib

[ruby-core:83123] [Ruby trunk Bug#13978] Remove Bundler from StdLib

[v.ondruch]

Issue #13978 has been reported by vo.x (Vit Ondruch).

----------------------------------------
Bug #13978: Remove Bundler from StdLib
https://bugs.ruby-lang.org/issues/13978

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: ruby 2.5.0dev (2017-10-03 trunk 60107) [x86_64-linux]
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN
----------------------------------------
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.


[1]: https://github.com/rubygems/rubygems/issues/1681
[2]: https://github.com/rubygems/rubygems/compare/2.6...master



-- 
https://bugs.ruby-lang.org/

[ruby-core:83125] [Ruby trunk Bug#13978][Rejected] Remove Bundler from StdLib

[hsbt]

Issue #13978 has been updated by 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.

----------------------------------------
Bug #13978: Remove Bundler from StdLib
https://bugs.ruby-lang.org/issues/13978#change-67069

* Author: vo.x (Vit Ondruch)
* Status: Rejected
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: ruby 2.5.0dev (2017-10-03 trunk 60107) [x86_64-linux]
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN
----------------------------------------
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.


[1]: https://github.com/rubygems/rubygems/issues/1681
[2]: https://github.com/rubygems/rubygems/compare/2.6...master



-- 
https://bugs.ruby-lang.org/

[ruby-core:83133] [Ruby trunk Bug#13978] Remove Bundler from StdLib

[v.ondruch]

Issue #13978 has been updated by 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.

----------------------------------------
Bug #13978: Remove Bundler from StdLib
https://bugs.ruby-lang.org/issues/13978#change-67077

* Author: vo.x (Vit Ondruch)
* Status: Rejected
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: ruby 2.5.0dev (2017-10-03 trunk 60107) [x86_64-linux]
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN
----------------------------------------
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.


[1]: https://github.com/rubygems/rubygems/issues/1681
[2]: https://github.com/rubygems/rubygems/compare/2.6...master



-- 
https://bugs.ruby-lang.org/