A) Duplicate code sucks up storage space, and bandwidth to transfer it around. There was a time, in living memory, when this argument was strong. But it became moot several years ago when they started giving away free encyclopedias in my breakfast cereal.
B) Duplicate code sucks up memory in running processes. This argument is still potentially strong, but without getting into the important Ruby-centric details (Can separate processes usefully share Ruby code anyway? What are the mechanisms for that? Do people really often run more than, say, two Ruby interpreter codebases on any given machine?) let's just point out that this is premature optimization -- especially in 2011, when RAM is cheap, boxes are cheap, everything is virtualized, and you should probably be running every application in its own virtual server anyway.
In the general case, it is more important that code be simple to install, correct, and reliable than that it have a light memory footprint. If you are smart enough and motivated enough to understand the need to optimize your software you have the tools to do so.
C) Duplicate code creates management headaches. You think you've updated the gem, but you've really only done so in one place. You forgot the other six places.
This is a real concern, but RVM plus Bundler represents an improvement, not a regression. For one thing: Before RVM there were several incidents where I battled the infamous `gem install` vs `sudo gem install` dichotomy. That problem -- getting every app and library to load the right library path without using RVM -- is an order of magnitude more confusing than anything in RVM.
I agree completely with A for most things outside of embedded systems, and even those are generally getting more and more space, and Ruby isn't really ideal for that anyway.
I disagree with B somewhat. I currently have a machine running about a dozen different Rails applications with no problems at all. I am indeed unhappy with the fact that Ruby does not share code better, because I could either save money on monthly costs or add more applications (I do know about "Enterprise" Ruby but prefer to stick with the system version). And yes, memory is cheap, but costs do multiply when you have to pay for extra ram every month (ala Linode). I also don't want or need the overhead for separate virtual servers for each and every application I happen to write unless they get big.
However, yes, C) is really the main concern. And I've found that just using system (root) level gems is the best way of keeping everything sane. I don't install per-user gems. So for me RVM/Bundler represents a real extra step and more things to know about than just gems by itself.
In the end, I use Ruby a lot these days, so I'm not unhappy with RVM. It's well done, and generally a good thing. I guess I just don't like the direction it seems to represent: packaging each thing in its own world. I prefer a shared world with divergences only where they are required.
What's the extra step to know with Bundler? I learned it in --- not exaggerating --- under 5 minutes. It took longer to run than to learn.
Now, instead of typing looking up the list of gems I need to install and then typing a bunch of gem commands, I copy my skeleton Rails Gemfile (which is literally just a list of gems with "get them from gemcutter" at the top), type "bundle install bundle", and I'm absolutely done.
You seem to be dodging 'mechanical_fish's point: Bundler improves the process. It isn't "more"; it's "better". They should have just called it Gem 2.0.
For the most part, I don't mind bundler, but I think it's too early to say it's overwhelmingly and only an improvement.
I can think of two cases where it concerns me:
1) I'm now supposed to type, for example, `bundle exec spork` instead of simply `spork`. This is extra typing, an extra thing for me to remember and it causes binaries to load/launch/start more slowly. (Yes, I've timed it.)
2) Bundler seems to break things in odd, hard to debug ways. I hang out a reasonable amount in #rvm on Freenode, and not an hour goes by that someone doesn't come in with a complex, hard-to-solve issue involving rvm, bundler, $LOAD_PATH and I don't know what else.
I admit that (1) is maybe somewhat petty, and (2) is probably not all bundler's fault. Still, I continue to have very mixed feelings about bundler. (My current compromise is that I only use it for Rails apps.)
Bundler is designed for its primary use case: web apps.
(1) is acceptable for web apps because they need to start once and stay alive until the next redeploy. Granted, the starting time is pretty stupid for desktop apps and even command line apps like the RSpec runner, but as people have already mentioned web app developers who deploy on Debian are the biggest part of the Debian Ruby userbase.
(2) shouldn't ever happen. Bundler is designed exactly to avoid inconsistent breakages, e.g. breakages that happen in production but not development. Bundler guarantees that things fail in the same way in any environment. If something fails then that means you're missing an entry in your Gemfile. I'd like to have a look at your problem.
(2) wasn't my problem; it's problems I've seen (repeatedly) in irc, as I said. For some (random) examples of people with issues related to bundler (ghost gems, gems that can't be found though bundler itself installed them), see the last handful of posts on this thread: http://yehudakatz.com/2010/09/30/bundler-as-simple-as-what-y...
As for the primary use case being web apps, I suppose that makes sense, except... Except that the Ruby community (or large parts of it, at least) are now suggesting that all Ruby development be done using bundler. And bundler itself also includes a jeweler-like/hoe-like tool to jump-start new gems.
I don't want to overdo it: I don't vehemently object to bundler, but it's size, dependency chain, strong opinions and (to me at least) apparent desire to take over the gem ecosystem make me a little worried.
> Except that the Ruby community (or large parts of it, at least) are now suggesting that all Ruby development be done using bundler.
I don't agree with that either. I think that there are legit as well as illegitimate use cases and that people don't always understand which is which. That said, I don't think it's any reason to dismiss Bundler.
I believe the core of Bundler - the multiple gem activation algorithm - should be part of RubyGems itself. If that is part of RubyGems then it would take away the need to use Bundler for many non-web app projects.
In general, there are a few possible answers:
A) Duplicate code sucks up storage space, and bandwidth to transfer it around. There was a time, in living memory, when this argument was strong. But it became moot several years ago when they started giving away free encyclopedias in my breakfast cereal.
B) Duplicate code sucks up memory in running processes. This argument is still potentially strong, but without getting into the important Ruby-centric details (Can separate processes usefully share Ruby code anyway? What are the mechanisms for that? Do people really often run more than, say, two Ruby interpreter codebases on any given machine?) let's just point out that this is premature optimization -- especially in 2011, when RAM is cheap, boxes are cheap, everything is virtualized, and you should probably be running every application in its own virtual server anyway.
In the general case, it is more important that code be simple to install, correct, and reliable than that it have a light memory footprint. If you are smart enough and motivated enough to understand the need to optimize your software you have the tools to do so.
C) Duplicate code creates management headaches. You think you've updated the gem, but you've really only done so in one place. You forgot the other six places.
This is a real concern, but RVM plus Bundler represents an improvement, not a regression. For one thing: Before RVM there were several incidents where I battled the infamous `gem install` vs `sudo gem install` dichotomy. That problem -- getting every app and library to load the right library path without using RVM -- is an order of magnitude more confusing than anything in RVM.