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.
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.
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.
Yes. I see the security implications of running an outdated $OTHERLIB, but that's $LIB's responsibility, no matter whether they include a copy of $OTHERLIB as its own package in a subdirectory or whether they just copy $OTHERLIB into their own code base.
Once you bundle dependencies, you're responsible for security holes in them.
The other issue of course is RAM usage once you start running multiple identical copies of $OTHERLIB, but that's only if they use identical versions. If it's different versions, you will have to run multiple copies at once or you risk breaking your dependencies. Or you don't run at all (Bundler's "solution")
Only when debugging. But that's a pretty big 'only when'
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.
Perhaps a better one would be "Bundler to be integrated into Rubygems"
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.
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.
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.