Bundler to be integrated into Rubygems
github.com
Bundler to be integrated into Rubygems
1–10 of 26 posts
Re: Bundler to be integrated into Rubygems
#2Despite 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"
Re: Bundler to be integrated into Rubygems
#3From 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. 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.
Re: Bundler to be integrated into Rubygems
#4From 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 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.
Re: Bundler to be integrated into Rubygems
#5Despite 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"
The title has been changed. What was it before?
Re: Bundler to be integrated into Rubygems
#6Re: Bundler to be integrated into Rubygems
#7What 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.
Re: Bundler to be integrated into Rubygems
#8From 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…
It sounds like npm quite easily can become a dependency hell where you have no idea whatsoever what code is actually being run.
Re: Bundler to be integrated into Rubygems
#9Earlier 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…
It sounds like npm quite easily can become a dependency hell where you have no idea whatsoever what code is actually being run.
On one hand that's certainly true. On the other: Do you care how $LIB does some work for you? Does it matter to you whether $LIB uses $OTHERLIB in version 0.1 or 0.2? Does it matter to you whether $LIB bundles $OTHERLIB as a package or whether it just includes the source code of $OTHERLIB?
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")
Re: Bundler to be integrated into Rubygems
#10From 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…
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.