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.

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.

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.

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

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

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.

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.

Requiring an exact version of Ruby for a project is a practice that avoids rare issues of version inconsistency.

If they're rare, you ought to identify them, and, rather than require an exact version, say "this version or greater", and spell out exactly why in the comments, so that future users of your code will know precisely what code is affected and be able to reason about it themselves.

That only works if all future versions are guaranteed to be backwards-compatible with the current version. A guarantee that does not exist.

See here:

http://yehudakatz.com/2010/08/21/using-considered-harmful-or...

A version requirement is a statement that "I have tested this code with these versions of the dependencies and verified that it works." Yes, given sufficient time and energy one can also test the code against many older versions of the dependencies, find any bugs, and include explanatory comments, as you suggest. But one can't test against the dependencies as they will exist in the future.

It's not the sort of thing that's easy to prove empirically one way or the other, but I get the feeling (despite being a heavy user and fan of Ruby) that other languages take that guarantee more seriously. It's a tradeoff: by not spending much effort on backwards compatibility, they can spend more time developing "cool new stuff". Users get more new stuff faster, at the expense of having to worry more about upgrades breaking things.

On the contrary. People on real production environments encounter the lack of compatibility guarantee all the time. Bundler is a way to guarantee compatibility regardless of actual future release compatibility.

> other languages take that guarantee more seriously

In general this seems to be true, but they do so on a best-effort basis. None of them provide perfect guarantee; that is, if there's some kind of law that would allow you to sue them $1000000 every time they break compatibility you would be VERY rich by now.

For example many people who use Python in production environments use virtualenv to guarantee compatibility. Virtualenv has a similar function to Bundler. Java people just tend to vendor specific versions of dependencies and don't rely on shared dependencies at all.

Even high-profile libraries that have extremely well-defined compatibility guarantees - such as GTK - tend to mess up from time to time. A few years ago they made a change in GObject. If you upgraded GTK then that would break the GNOME login manager, rendering your desktop useless (this problem was later fixed).

Breaking compatibility because of human error happens all the time, and often in unexpected ways. Bundler and similar tools provide protection against that in return for a bunch of other disadvantages. The point is you can't see compatibility as an either-perfect-or-nonexistant thing.

It's more than just a feeling. They certainly do.

But: Those languages are there. They live! Perl 5, for example, is there. It has not gone anywhere. Its community would love for you to use it. The fact that some people sometimes decide to use other things tells us something about the value of backwards compatibility in uncertain times.

My impression is that Ruby does change uncomfortably quickly, but not so quickly as its problem domains are changing. The rate of change of our software ecosystems is a symptom, not a cause. My god, the things that have happened in the last decade. Cheap virtual machines in the cloud. Widespread use of distributed version control. Client-side web apps. Mobile applications. NeXT cubes in your pocket for $250.

Java, which seems to take it fairly seriously, is way more popular than Ruby is.

I agree that the world changes quickly, but disagree that you need to radically change stuff all the time.

For instance, in Rails, they went from <%= to <% back to <%= for forms. To me as an end user, that is completely useless churn.

Like I've said, I like Ruby and am mostly happy with it, but there's a tendency to rush off after the 'latest new thing!' that at times I view as counterproductive.

As for the Rails <%= thing, where did you get the idea from that they went from <%= to <% and back to <%=? Did all of this happen within the same release minor release cycle? Rails has a strong compatibility policy for minor releases and only tend to break things between different minor releases.

The tag thing in Rails has happened over time, not in the same release cycle, but still it's annoying.

Yes, I am. Just because they have a policy in place doesn't mean that I lose my right to air my opinions.

The point with the <% thing is that it feels a bit too much like gratuitous code churn to me. <%= is what you use to output something, and you do want to output a form, so <%= is what they should have stuck with from the beginning.

I could be off, but I think rails 1.2 did that.

Much of what we see here is a dev/ops culture clash. Sysadmins like well-established system-level packaging systems like .deb and .rpm. They like them because they have well-established semantics ("this thing is obviously a security patch; that thing is probably a feature upgrade"), and they like them because these systems abstract away the need for the admin to understand the details of the release model of five or ten or a hundred different open-source ecosystems.

Part of OP's complaint is that (from his perspective) the Ruby community has release semantics that he doesn't understand. Is that patch to Ruby 1.8.7 really just a "security fix"? Can it probably be safely applied to 1,000 production servers without causing downtime?

---

[1] I should note: I'm not accusing Ruby developers, or any other developers, of ever having done any of these things. But these are the dark thoughts that keep engineers up at night. Especially when managing codebases built on ecosystems that they don't intimately understand.

* Use apt-get for pretty much everything.

* Locally install a few project specific things. These often are installed locally, not system-wide, and have nothing to do with root.

* Use rubygems. It's nice, but I don't have the same level of confidence in it regarding security that I do about Debian and Ubuntu. It seems to just give me 'updates' to gems, without much of a way of knowing which updates are security fixes and which are simply improved versions of the packages in question.

RVM adds one more thing. And for each Ruby instance in there, I might have various versions of gems floating around. This does not make me happy from a security point of view.

  $ rvm install ruby-head-r29837 --patch refinements.diff

Also, Debian takes a lot of efforts to make different major versions run in parallel, like Ruby 1.8 and 1.9, Tcl 8.4 and 8.5 and so on.

Also, large packages like Ruby often have a boat-load of customizations and patches applied to them that may not apply cleanly to subsequent releases of that software. Modifying a debian package to build a new version is significantly more nightmarish than the RVM install process.

rvm is easier than creating your own deb or rpm

rvm is easier than doing your own packages, certainly, but imagine if you had to use an 'easy', but different tool for everything on your systems.

Also, 'easy' it may be, but I'm not convinced of how things will work out in terms of security, whereas I have a lot of trust in Debian and Ubuntu's security teams. Time will tell, I suppose.

For example, if I'm a ruby developer that ends up using different platforms often (osx, debian, centos) then it's justifiable that I want to use a packaging abstraction that's platform agnostic but ruby specific.

If I'm a primarily a debian user that happens to program in ruby and a dozen other languages then I would prefer a packaging abstraction that's tool agnostic but debian specific.

Or, at work it's basically the same thing but with java and maven to manage java stuff. Java's had a similar history of butting heads with package management systems.