

Bundler to be integrated into Rubygems - emyl
https://github.com/jruby/jruby/issues/1146#issuecomment-29714318

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

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

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

~~~
xs_kid
Right and the guy of the last comment of the issue is proposing also an
solution for it:

[https://github.com/soveran/cargo](https://github.com/soveran/cargo)

~~~
stormbrew
No matter what it's too leaky an abstraction. Everything in the stdlib uses
require. Every fundamental piece of ruby code not in the stdlib uses require.
The process of getting from point A to point C involves crossing a point B so
frustrating, limiting, and ugly no one is really willing to cross it.

Ruby's global constant namespace was probably a mistake in hindsight, but at
this point it'd be a language fork to change it meaningfully.

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

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

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

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

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

------
NoCowLevel
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?

------
aaronbrethorst
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
The title has been changed. What was it before?

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

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

