rubygems / rfcs

RubyGems + Bundler RFCs
45 stars 40 forks source link

RFC on merger with RubyGems #18

Closed indirect closed 5 years ago

indirect commented 5 years ago

It's happening!!! 🎉

Rendered

jules2689 commented 5 years ago

I understand and appreciate the overall idea, but it does raise a bit of a question around competition. When rubygems and bundler are together, there will be less incentive and it will make less sense to create tools like gel, which has already spawned some healthy discussion.

Competition encourages the betterment of everything, and merging the 2 projects may inhibit that.

EDIT Questions resolved: https://github.com/bundler/rfcs/pull/18#issuecomment-486321260

indirect commented 5 years ago

@jules2689 can you elaborate on what you think will be different? Today, Bundler and RubyGems both already depend on each other’s internals, and that didn’t stop Gel from happening.

jules2689 commented 5 years ago

Bundler relies on Rubygems internals, I knew that. But I didn't think Rubygems relied on Bundler in any way.

I'm not saying it's a blocker, but a potential downside. Having these so tightly coupled as to become one would kind of discourage competition IMO. Gel could happen because Rubygem's sole responsibility is to host gems. Bundler does all the fancy stuff with collecting gems, dependency resolution, etc. There is a clear line that isn't crossed, which means anyone can replace the latter half. When they are combined to one, that line is fuzzy and concepts blurred, such as the differentiator I used in #17 to determine that Bundler is a more appropriate place to put the error handling. Given that that line would be completely grey, a library maintainer for something like gel would not be able to rely as easily, I'd think, on just the Rubygems portion without fear of "this is literally only made for Bundler now, well it is bundler now".

This is speculation alone, of course.

deivid-rodriguez commented 5 years ago

Rubygem's sole responsibility is to host gems. Bundler does all the fancy stuff with collecting gems, dependency resolution, etc.

This is not true. rubygems.org responsability is to host gems, and it's not going anywhere. The rubygems CLI does essentially the same thing as the bundler CLI, only in a more limited way.

jules2689 commented 5 years ago

The rubygems CLI does essentially the same thing as the bundler CLI, only in a more limited way.

That is a fair point. I had conflated the two, and I think the distinction is more clear in my mind now. Thanks for bringing that up.

indirect commented 5 years ago

Copied over from bundler/rfcs#17, here's a brief explanation of each project:

RubyGems.org: provides 1) a list of all gems, 2) gemspecs, and 3) the .gem files. There are a few different formats for that data, but that's the gist.

RubyGems: provides 1) the gem command, 2) a monkeypatch to require that knows how to find installed gems, 3) the Gem class and everything underneath that.

Bundler: provides 1) the bundle command, and 2) the bundler/setup Ruby file that monkeypatches require (and a lot of other parts of RubyGems) to limit it just to the single application bundle, and 3) the Bundle class and everything underneath that.

As you can maybe imagine, Bundler depends on lots of RubyGems internals, and in the last few years we have been starting to consolidate places where RubyGems and Bundler have two different classes to do the same thing with a single class that both of them use. For example, they both share the same dependency resolver, Molinillo, and they both share the same client for the newest API to get information about gems.

segiddins commented 5 years ago

they both share the same client for the newest API to get information about gems

I don't believe this is true yet, I don't think the compact index is supported by RubyGems

colby-swandale commented 5 years ago

@indirect We also need to figure out what we'll want to do with bundler.io as well.

indirect commented 5 years ago

@segiddins good point on the compact index not being implemented inside RubyGems yet. Hopefully we can avoid having two copies of that functionality, and reuse one copy instead. 😬

@colby-swandale so far, I had been imagining that bundler.io would continue to host the docs for the bundle command, but I am open to other possibilities.

indirect commented 5 years ago

Thanks for the feedback, everyone! Here we goooooooo......