Bundler to be integrated into Rubygems • Hacker News Board

Re: Bundler to be integrated into Rubygems

#21

Post by jrochkind1 » Wed, Dec 04, 2013, 3:56 AM UTC

regularfry wrote: post #7

What was the logic behind rubygems adding support for Gemfiles? I can see why Gemfile.lock support is a good thing, but adding a new, incompatible runtime dependency resolution mechanism to that provided by Bundler seems like an odd choice.

Gemfiles _are_ bundler's dependency resolution mechanism; it's not a new incompatible mechanism added to that provided by bundler -- it's bundler's mechanism being merged into rubygems itself.

Which is great news, in my opinion. With the same team, release schedule, and set of tests, there will no longer be issues of which version of bundler works with which version of rubygems (which isn't an issue except when it has been, and then it sucks, especially for newbies). No extra thing to install (including in your provisioning/deployment scripts). It's just there, it just works. The number of seperate interacting parts you had to install to 'bootstrap' a proper ruby installation has been growing -- which really does add increased burden to newbies understanding what's going on -- nice to shrink it again.

Re: Bundler to be integrated into Rubygems

#22

Post by tomphoolery » Wed, Dec 04, 2013, 5:34 AM UTC

rschmitty wrote: post #18

plorkyeran wrote: post #4

Earlier quoted context omitted.

With Bundler, you have a single copy of each (version of each) library installed, and Bundler decides at runtime which to make visible (which is trivial with Gemfile.lock, since all of the interesting logic is done when creating that). This decision is a global one, so if you depend on two libraries that themselves depend on libfoo, both of those libraries have to use the same libfoo, and there's no difference betwee…

Can't you just "vendor everything" and now each project will install all of the gems locally to vendor and not be concerned about global choices? http://ryan.mcgeary.org/2011/02/09/vendor-everything-still-a...

Sure, but if you use Git this can get pretty hard to deal with especially on large repos with lots of history. A `git clone` downloads an entire repo, and all of its history...so if you have a bunch of gems or executables in there that boosts the contents of your repo tremendously.

This is why there is `bundle install --deployment`, which "freezes" the Gemfile and ensures it has not changed from what has been committed to the repo. If it has, `bundle install` will not succeed.

Re: Bundler to be integrated into Rubygems

#23

Post by tomphoolery » Wed, Dec 04, 2013, 5:37 AM UTC

plorkyeran wrote: post #4

ollysb wrote: post #3

From the bottom of the comments on that issue: sovereign> @drbrain It's a different approach, where a dependency resolver in runtime is no longer needed. I've been using that approach for the past six years, and during all that time I have been the happiest rubyist in town while my friends struggle with Bundler. The idea is to trade space for complexity. Once the gems are installed in isolation, there's no need for d…

With Bundler, you have a single copy of each (version of each) library installed, and Bundler decides at runtime which to make visible (which is trivial with Gemfile.lock, since all of the interesting logic is done when creating that). This decision is a global one, so if you depend on two libraries that themselves depend on libfoo, both of those libraries have to use the same libfoo, and there's no difference betwee…

I do like npm's simplicity. You used to have to be really careful with the versions, because if you didn't specify it would just download the latest version, and sometimes some of your dependencies would use the wrong versions of libraries and APIs would change and things go haywire. I think they've fixed a lot of that now, though...it was certainly easier a few months ago than it was a few years ago.

Re: Bundler to be integrated into Rubygems

#24

Post by NoCowLevel » Wed, Dec 04, 2013, 7:57 AM UTC

I've probably been living under a rock, so Bundler dying in two years comes as a real surprise. Does anyone have a link or two with more info?

Re: Bundler to be integrated into Rubygems

#25

Post by regularfry » Wed, Dec 04, 2013, 9:09 AM UTC

jrochkind1 wrote: post #21

regularfry wrote: post #7

What was the logic behind rubygems adding support for Gemfiles? I can see why Gemfile.lock support is a good thing, but adding a new, incompatible runtime dependency resolution mechanism to that provided by Bundler seems like an odd choice.

Gemfiles _are_ bundler's dependency resolution mechanism; it's not a new incompatible mechanism added to that provided by bundler -- it's bundler's mechanism being merged into rubygems itself. Which is great news, in my opinion. With the same team, release schedule, and set of tests, there will no longer be issues of which version of bundler works with which version of rubygems (which isn't an issue except when it ha…

> Gemfiles _are_ bundler's dependency resolution mechanism

No, Gemfiles are the dependency specification protocol. The resolution mechanism is the algorithm which turns that into a set of gems to install or, if you're feeling particularly crazy, require.

Right now I can have a Gemfile which bundler accepts, and rubygems barfs on. That's the incompatibility.

Re: Bundler to be integrated into Rubygems

#26

Post by jrochkind1 » Wed, Dec 04, 2013, 10:35 PM UTC

regularfry wrote: post #25

jrochkind1 wrote: post #21

Earlier quoted context omitted.

Gemfiles _are_ bundler's dependency resolution mechanism; it's not a new incompatible mechanism added to that provided by bundler -- it's bundler's mechanism being merged into rubygems itself. Which is great news, in my opinion. With the same team, release schedule, and set of tests, there will no longer be issues of which version of bundler works with which version of rubygems (which isn't an issue except when it ha…

> Gemfiles _are_ bundler's dependency resolution mechanism No, Gemfiles are the dependency specification protocol. The resolution mechanism is the algorithm which turns that into a set of gems to install or, if you're feeling particularly crazy, require. Right now I can have a Gemfile which bundler accepts, and rubygems barfs on. That's the incompatibility.

I see what you mean, yeah. If I understand it right, this is a temporary state of affairs, as the rubygems/bundler integration is only partway done.

The end goal is rubygems handling of Gemfiles and Gemfile.lock will become equivalent with bundlers, and then bundler will disappear.

I am curious why they decided to even release the partial implementation on the way. Either way, I'm grateful enough that a rubygems/bundler merge is happening, and we'll never need to deal with incompatibilities between certain versions of rubygems and bundler again once it does, that I'm willing to not be too picky about how they get there.