Anyway, Bundler is an ambitious attempt to grapple with a real, very difficult problem domain. Dependency resolution is hard, bug-prone, and painful on almost every platform. Python’s easy_install is often anything but easy, Java’s maven/ivy has plenty of issues, and OSGi is very complicated. As far as I can tell, the problem just sucks on every platform.

Why Rubygems seemed less painful than these so far is due more to the fact that the Ruby ecosystem is relatively young, agile, and fast-moving versus older and more established platforms. As Ruby dependencies get bigger, older, and more heavily used I believe that we will move closer to the messes that other languages have. The increasing tendency of developers to “vendor” or unpack gems in Rails projects (sometimes adding their own patches to make them work) is a troubling sign that we’re moving in this direction, away from a reproducible, more formal approach to something more ad-hoc and prone to ossification. Believe me, we don’t want to become the Java world. See http://yehudakatz.com/2010/04/12/some-of-the-problems-bundler-solves/ for a subset of the problems we’re beginning to face.

Given that, I can excuse a good deal more pain from Bundler–which is still prerelease–than I would many other tools that I use. I’ve found a few times that problems it’s presented have been more “canary in the coal mine” style things that otherwise would have popped up at runtime. And I’ve found having a better understanding of what Bundler is trying to do and how it works has helped me immensely in solving these issues.

As far as your specific issues with Bundler, here are a few thoughts:

1. You’ve been using Bundler since 0.7.6; I’ve been using it since 0.9.something. Anecdotally, I’ve seen far fewer issues and haven’t had to deal with any breaking API changes. Bundler is definitely in an alpha-like state (if that means anything) even though the rest of Rails 3 seems far more stable and complete.

2. You really don’t need to use Bundler with Rails 3 at all! As others noted, just change boot.rb to point to whatever you’re using. The thing that makes me happiest about Rails 3 is the fact that it’s so much more decoupled from its various dependencies, Bundler included. From our work together, I suspect that the new direction Rails has taken with version 3 may be something we disagree on.

3. The way your coworker was treated by the Bundler developers seems pretty shabby, and it too bad.

Anyways, good to see your name pop up! I hope you’re doing well.

I just want to add that changing “config/boot.rb” in Rails 3 is not a curse. In Rails 3, “config/boot.rb” is a small and clean file which basically sets up your load path. There is no more lots of complex ruby code neither a “don’t touch me” logo stamped.

For instance, you could simply have one line in your “config/boot.rb” saying “require ‘rubygems’” and it would work.

Yehuda and Carl worked on a clean “config/boot.rb” file exactly because if someone wants to use bundler, rip or rubygems, that should be configured in “config/boot.rb”. Otherwise is too late.

Regards!

ps: btw, I checked the “notify me of follow-up comments” box but I never got any e-mail.

There are really only three tasks to accomplish related to gems, and Rails 3 makes it easy to do these tasks however you want by modifying boot.rb and environment.rb:

A. Install gems (can be manual or part of app startup): ‘gem install foo’ from command line
B. Activate gems (put them on the load path): ‘gem “foo”‘ once you have loaded rubygems, or inspect the gemspec and manage the load path yourself.
C. Require files from gems: once they are on load path, should just be require ‘gemname’ for well-packaged gems

Sounds easy, but just look at Bundler’s feature list and you’ll see all the little edge cases that make it hard.

Here’s the alternatives to accomplish these tasks. I would STRONGLY recommend #1…

1. Stick with Bundler and stop complaining about prior release instability, since the roadmap now indicates there shouldn’t be any more breaking changes to the config file format.

2. Do it yourself, using any of the alternate approaches described above.

3. Use GemInstaller (which I don’t recommend even though I wrote it, because Bundler is superior)

4. Don’t use Rails 3, which is pre-release software (please leave the alpha vs. beta arguments, it’s just new stuff that is being worked out, and worked out well and responsively if you ask me).

Notice I didn’t mention anything about config.gems, because that’s not an alternative. The config.gems approach was fundamentally flawed – you CANNOT manage dependencies AFTER your app is already in the initialization process. It is too late. You definitely can’t use that approach to manage rails itself. You must set up your load path before anything else starts, which is why I added the preinitializer.rb patch to rails 2.x to support GemInstaller.

So, my main point is that Rails CANNOT go back to config.gems. That’s not an option. Given that, the best thing to do is to embrace Bundler, help report bugs, help fix patches, and support it just like you support all the other awesome improvements Carl and Yehuda have made to Rails.

Thanks,
– Chad

I don’t find this post particularly useful in the sense that it identifies a problem, but doesn’t suggest a solution, so I suppose it qualifies as merely a rant in that sense. Maybe that’s because at this point, what can be done for Bundler is being done, as Yehuda describes quite courteously in the comments above. The author could have spelled out some alternatives, but I suppose his thinking was that would leave him open to the “you don’t have to use Bundler” argument (which is irrelevant – it’s the default, the default in a beta stack should function at a beta level; it doesn’t).

I’ll try my hand on the suggestions. Instead of fighting it out each day in the blogosphere, wouldn’t it be great if the Rails core team simply published something along the lines of:

“Bundler. Phew! That one is tough.”

“It’s been a long road to the Rails 3 beta release, and we’re very proud of what we’ve accomplished. Since the beta announcement we’ve received a lot of great feedback and worked hard to incorporate it. In particular we’ve learned that managing gem dependencies is a tough nut to crack. Our beta of Bundler, the default dependency management solution for Rails, has seen quite a few updates since that release, many of which broke earlier versions. For a lot of users who are just dipping their toes in the water, this is par for the course and everything works pretty ok. For others, we’re hearing LOUD AND CLEAR that it has been a major headache. For that we apologize. In an effort to ease the pain, we’ve published a clear roadmap that will hopefully make the future a little easier to navigate. Keep in mind however, that critical bugs can force us to change even the best laid plans. And if you want to pitch in, by all means keep it up with the bug reports and patches.

If it’s all too much to bear and you want to forge ahead without using Bundler, here are some alternatives….”

and so on… point being:

1) Acknowledge the obvious – that Bundler is a core part of Rails, and it turned out not to be as ready for beta as the rest of Rails.

2) Say you are sorry. Is it that hard, even if you don’t really mean it? Saves time.

3) Offer some concrete alternatives (which I’ve only ever seen enumerated defensively as replies to angry blog posts).

Try this, and maybe everyone can go back to writing informative posts with helpful tips for newbies like me, instead of these “at war with ourselves” things.

Get over yourself. I thought apologizing when you didn’t do anything wrong was only expected of people working at ThoughtWorks.

Every platform and tool-chain has the same issues. Most solve it without much fuss. There is no one true way. Just ways that work more or less, with advantages and disadvantages.

The difference with .NET (when I used it anyways), was that using the GlobalAssemblyCache was a manual process. The default was what we’d call vendoring. And because the big languages are statically compiled, any issues with version conflicts would show up at compile time, forcing you to address them as they came. It wasn’t fun, but it’s not as if you’d spend a majority of your time managing dependencies between assemblies either.

When the tool you depend on in being pimped as Beta, but developed as an Alpha spike, that goes into the “disadvantage” column.

Apologize? Seriously? For such a reserved, non-rant? Ridiculous.

What I get is that the problem is a really hard one: you and lots of other smart people have worked on it without coming to a completely satisfactory solution. My guess is that AFTER Bundler has been stable and in successful use for a year or two, someone will be able to improve it — at which point replacing boot.rb will indeed be an option for Rails 3.

For the present, seems to me that BJ’s team should spend their energy just as they’re doing — in creating a patch to improve Bundler.