Bundler to be integrated into Rubygems

https://github.com/jruby/jruby/issues/1146#issuecomment-29714318

by emyl • 13 years ago

113 24 13 years ago

github.com

aaronbrethorst2• 13 years ago

Despite being a quote from the maintainer, this is a needlessly link-baity title.

Perhaps a better one would be "Bundler to be integrated into Rubygems"

swang• 13 years ago

The title has been changed. What was it before?

aaronbrethorst2• 13 years ago

"Bundler is scheduled to die in under two years time"

ollysb2• 13 years ago

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 dependency resolution in runtime. </sovereign

Isn't the point of the Gemfile.lock that your dependencies are not resolved at runtime? If I've misunderstood I'd really appreciate an explanation of the difference compared to say NPM. I've also never seen any practical difference between NPM and Bundler and have often wondered why people like the NPM implementation so much.

plorkyeran2• 13 years ago

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 between having a direct dependency on libfoo and depending on a library that depends on libfoo.

With npm, each library has its own set of dependencies (and those libraries have their own sets of dependencies, and so on) that are entirely separate. Thus, if you depend on two libraries that use libfoo, those two libraries have their own copies of libfoo - and those two copies can be different versions, if needed (and if libfoo depends on libbar, you'll have two copies of that too). This makes the presence of dependencies much less leaky and eliminates most problems with incompatible gem versions at the cost of wasted disk space, (usually trivially) increased memory usage and some potential confusion. It also happens to make npm pretty mind-numbingly simple compared to bundler's dependency resolution logic.

yxhuvud• 13 years ago

It sounds like npm quite easily can become a dependency hell where you have no idea whatsoever what code is actually being run.

djur• 13 years ago

Rubygems doesn't have the luxury of providing that kind of system, though, because of how 'require' works in Ruby. AMD/RequireJS allows requires to be scoped, while Ruby requires dump directly into the global namespace.

rschmitty• 13 years ago

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...

tomphoolery2• 13 years ago

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.

regularfry2• 13 years ago

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.

jrochkind14• 13 years ago

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.

regularfry2• 13 years ago

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.

znowi• 13 years ago

And here comes the bloat. Soon Rails will be replacing WEBrick in Ruby 3.0.

jrochkind14• 13 years ago

HOO RAY. Seriously. This is great news. Thanks drbrain!

NoCowLevel• 13 years ago

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?

Bundler to be integrated into Rubygems

Related Stories