Bundler: Oh the fail I know.

First, a disclaimer: I don’t want to be negative. I am only writing this because I feel it deserves attention by the community and because I love Rails so much that the fact that something is making me lose faith in it truly makes me a little sad.

I first started using Bundler 0.7.6 in December ’09 in a Rails 2.3.5 project. We also use Bundler (not sure what version we started with) in our main Rails 2.3.x app that powers www.Goldstar.com. In the 3+ months that we have been using bundler, it has, by far, been the largest pain point and time sink of any part of our toolset to the point that today, I proclaimed on twitter, than in it’s current state, I can’t recommend Rails 3.0 to anyone starting or upgrading a product.

Now, if you know me, you know that this is pretty out-of-left-field. I’m a HUGE Rails evangelist. And I truly believe that it’s right for many projects in all kinds of scenarios.

Anyway, on to the fail. . .

Bundler 0.7.x had lots of issues, too numerous to count. However, it did have the option to pass a yaml file to it via –build-options that would allow you to pass a few arguments into the various gems it needed to build. This was good enough for us, and we followed the convention we use with database.yml to have all the correct options in the various environments we use to dev/deploy our rails apps.

Builder 0.8 soon followed suit (I believe in January) and messed us up by changing the path inside the bundler folder that all the gems where kept at to be name-spaced to what version of ruby you were using. I’m not sure what this was meant to fix, but it broke a few things for us and it broke Rubymine (my personal editor of choice). But hey, we upgraded.

I’m going to leave out all the pain that was causes by upgrading to 0.8 and just say that we are currently using Bundler 0.8 in dev and production, except that a bug, where older version of already cached gems won’t upgrade unless you rm -rf the bundler directory (json-pure-1.2.2 to json-pure-1.2.4 fwiw) is breaking our deploys to production. This means that every deploy to production, we can’t be sure the bug isn’t going to break it, so we must rebuild every gem in the app (of which there are MANY) every time we deploy. This just isn’t going to work for us.

Now, we’d like to move to Bundler 0.9 because it promises to fix our issue (bundle install correctly updates gems as required). However, –build-options has been removed from 0.9. Because –build-options was removed, bundler has moved to a don’t-vendor-some-of-your-gems solution where it will use gems from the system if they aren’t in the bundle. This allows you to pass different incantations to `gem install` for different gems (mysql, pg, etc) and it will use those already built gems when you later do `bundle install`. But that means we’re back to managing gem installs on all of our different systems in different ways, which was one of the few things that Bundler did significantly better than config.gem!

Our systems developer, Steven Baker, is currently working on re-implimenting a solution to the –build-options issue, which he first ran by “Carlhuda” in hopes that they might include it and we’re not going down a road that will just end in us playing by ourselves and having to re-impliment our Gemfile or build_options.yml file for whatever solution is, but this brings me to my point:

Rails 3.0, because it relies on Bundler, is not in anyway stable/useable/suggested unless you want to pretty continuously fix/re-impliment/cry yourself to sleep because of Bundler. Carl L. has posted a roadmap which shows at least 2 more revisions as well as closing 20+ currently open issues. I have no idea what the issue velocity is on the project, but to me, it looks like it’s in the months and not days or weeks before Bundler is going to be stable. And, as with every version before it, there have been major downsides to the implementation, that have forced pretty major breaking changes. In other words, every version of bundler is a new experiment (not to mention the various gem management techniques that merb used which were also a source of headaches), and I have little confidence that just slapping 0.9 or 0.10 is going to change that.

Bottom line: A significant piece of Rails 3 is still in the “spike” phase, and shows little to no promise that it will become solid enough to trust for _months_.

Please skip the “Patches are accepted” (we’re working on one kthxbye) and “Why are you even using bundler?” (troll). I’m not here to indict or blame anyone, just to report our experience and clarify why I’ve lost significant confidence in Rails because numerous people have asked.

Sidenote: I’m putting this at the bottom, because it’s secondary to the point of the post, but why, precisely, do we *have* to use Bundler to make Rails 3 work? Who made this decision? If it was the same people that wrote Bundler, doesn’t anyone see a problem with that (NIH)? I’m assuming there were discussions in the rails-high-council private campfire room at some point, but obviously us peons aren’t privy to those. Config.gem wasn’t the easiest thing to use, but I’ve successfully used it for close to a year with very few issues and had it’s eccentricities worked out pretty well. To have it completely removed from Rails 3, and replaced by an experiment, seems a bit premature.

  • Hrm that sucks you’ve had problems. Bundler has worked OK for me (not flawlessly but good), but I do agree it’s kind of strange we’re making everything else so modular and adaptable while seemingly locking Rails into this one decision. I mean, if they can get it working really well, fair enough, but it seems like folks are having a lot of issues. :-/

  • rick

    the concern has been raised before. I believe the idea is that Rails will ship with bundler enabled, but make it possible to take it out. Just like it ships with ActiveRecord enabled. I could be wrong though…

    I’d prefer not to use bundler either, but currently my minimal usage of it is working out.

    • BJ Clark

      Rick, Thanks for the reply.

      You’re not the first to mention that bundler could be removed and we’re currently exploring how to replace it with rip, but it doesn’t exactly look straightforward or easy.

  • Agree almost entirely. I suppose I could live with bundler being as unstable as the most notoriously unstable gems (for me, cucumber and rvm), but its position as a strong default (although not compulsory) for Rails 3 is an issue.

    That said, I’ve always found config.gem to be a rotten solution to this issue, particularly on remote environments, and Bundler is a bug step towards addressing that.

  • Thank you for your honesty and for being brave enough to talk about this issue. We need more open, public discussion of design decisions like this.

    I’ve used Merb’s bundler in development and production for the past 2 years, and I hoped that the progress on Rails 3 would make it a smooth, painless experience.

    The confusing thing is that there are other options out there. People are having success with rvm. Chris Wanstrath’s rip is an attempt at solving this problem. “Vendor everything” is working pretty well for me right now. In other departments, competitors to the Rails defaults co-exist peacefully (RSpec, Haml, jQuery).

    Which brings up the question, what _is_ the problem? Is the bundler supposed to fix development or deployment problems? In my experience, Merb’s bundler definitely made deployment more awkward until the rebuild-on-every-deploy problem was fixed (which seems in limbo in the current bundler).

    Let’s explore the other options! It’s open source, after all.

    • BJ Clark

      Thanks for your reply Geoff.

      Your point about defining the actual problem is a great one. It’s too bad the Rails blog has gone silent. A post that illuminated what the problem is and whether this is a NIH problem, or if there are reasons Rip wasn’t used, or what’s going on would be really amazing.

  • Dan

    I agree I got really excited about bundler at first and we were using it in production. Because of various problems and failing deploys we had to rip it all out again. That is also after the headaches of doing several upgrades where as you mentioned broke things.

    Something so experimental probably shouldn’t have been pushed so into the use must use it category with the Rails 3 stuff. Get it working solid and then make it part of Rails 3.1.

    I really do appreciate all that Wycats and Carl have been doing with Rails and Bundler, but I think bundler isn’t quite as ready for the limelight as people thought.

  • Ok, I will try to answer some conceptual questions.

    1) How can I NOT use bundler?

    A) Rails 3 source code does not know anything about bundler, only the application it generates. So you don’t want to use bundler? Remove the bundler code from your config/boot.rb and config/application.rb, and that’s all. How can this be hard?

    2) What issue bundler is trying to solve?

    A) The ultimate issue bundler is trying to solve is the one represented in this tickets:

    https://rails.lighthouseapp.com/projects/8994/tickets/4031-having-rails-23pre-or-rack-11-installed-breaks-rails-2x

    https://rails.lighthouseapp.com/projects/8994/tickets/3685-actionpack-235-gem-declares-incompatibility-with-rack-110

    If you try to remove bundler from application, you should meet this error soon (if you haven’t personally). In my 2.3 apps, it happens a lot with rspec whenever a new version is released. It’s not rspec fault though.

    Since in rubygems we do not have a place to list our dependencies, the dependencies check happens at runtime and becomes hard to detect/fix. Bundler provides a single place to list all dependencies, resolve them and locks your load path, so you can access only the gems specified in the Gemfile.

    To use the functionality described above, you don’t have to use `bundler install` at all, which is a good thing and improvement compared to the previous versions. You install your gems as you wish and bundler will focus on locking your load path and dependencies.

    3) Can we have config.gem back?

    A) No, we cannot. Why? Because Rails is packaging system agnostic (as I said, you can remove bundler) and config.gem was too coupled with rubygems.

    4) Why Bundler 0.8 “messed us” up by changing the path inside the bundler folder that all the gems where kept at to be name-spaced to what version of ruby you were using?

    A) So bundler can work with multiple ruby versions. sqllite3-ruby compiles differently for Ruby 1.8 and Ruby 1.9 (for instance).

  • I don’t know where this idea came from, but it is completely wrong — Rails 3 does not and will not require you to use the bundler. Anyone who wants to use the bundler is welcome to use it, and anyone who wants to avoid it is also welcome to do that.

    Bundler has not yet hit 1.0, and as that implies, the API is not stable. If you would like to try Bundler before 1.0, I (and the rest of the bundler team) happily welcome bug reports, feature requests, and patches. Furthermore, there is a plan for stability and feature-completeness. The road map is written. Future changes are mapped out and available for you to understand and comment on. If you want to wait for a specific milestone before you try to use it, the roadmap should make it easy to figure out where that milestone is in the schedule.

    Please stop treating the bundler like it has reached 1.0, because it hasn’t. Rails 3 is a beta, and so is Bundler. Beta versions mean things don’t work, and things will break between versions. All that to say, Rails 3 happens to support Bundler out of the box. It’s not required, demanded, included, or anything like that. Bundler isn’t 1.0 yet, so it has bugs and is missing features. They will arrive, and when the ones that you need show up, I hope you’ll use it — but you definitely don’t have to now, and you won’t have to later.

    • First, we’re using Bundler 0.8 without much issue. So lucky us? We did patch it ourselves, but these days if we’re going to use a tool, we tend to fork it to avoid this sort of instability.

      That said, saying that you get to break everything with experiments every release because it’s beta is exactly why we left Rails. This usage of Beta is rather novel. Classically I think most developers would sort that attribute into the Alpha bin.

      But the trust that there actually is some sort of a game-plan, a list of requirements to meet, and that projects you depend on to make your living aren’t just large communal experiments is exactly the reason we went and developed our own framework.

      No more silliness with someone changing form-helpers for dubious benefit causing us days of work to keep current. Or breaking changes every release because it’s “beta”. At some point do your business a favor and ask yourself, how’d that whole LTS thing work out with Merb? Do you care about being able to jump on the latest, immature plugin for the hot new post-it-notes-in-the-cloud-database or do you care about delivering value to *your* clients?

      At the end of the day, we decided that we valued delivering working software over the latest experimental technologies.

      “That is, while there is value in the items on the right, we value the items on the left more.” 😉

    • BJ Clark

      I’m not sure which one idea you’re referring to, but I’ll just assume that you think the whole post is wrong. So either you disagree with my experience (which is pretty deep, man) or you think I need to STFU. That’s. . . unfortunate.

      As far as Bundler being “beta”, I think I pretty clearly explained that I agree, and I actually think it’s more like a spike or “alpha”. Which is the the point of the post, and what has me concerned. I also clearly stated skipping the “Why are you even using bundler” argument, since it would be trolling.

  • I’m afraid I have to agree 100% with the issues with Bundler. I Am using it on a new project, and the pain is very high. So far nothing we can’t work round, but way too expensive!

  • “Your point about defining the actual problem is a great one. It’s too bad the Rails blog has gone silent. A post that illuminated what the problem is and whether this is a NIH problem, or if there are reasons Rip wasn’t used, or what’s going on would be really amazing.”

    I would recommend reading Yehuda series of blog posts for more information:

    http://yehudakatz.com/2009/06/15/rubygems-problems-and-proposed-solutions/
    http://yehudakatz.com/2009/07/08/rails-bundling-revisited/
    http://yehudakatz.com/2009/11/03/using-the-new-gem-bundler-today/
    http://yehudakatz.com/2010/02/01/bundler-0-9-heading-toward-1-0/
    http://yehudakatz.com/2010/02/09/using-bundler-in-real-life/

    There is plenty information on those. 🙂

  • Hampton Catlin

    +1 to Andre.

    Sure, the breakages are quasi-annoying. But then I just remember that this is beta and also software that they want LTS on. So, the whole point of beta is to do these kinds of changes.

    Personally, I thank the bundler team. Even with one breakage since it went into beta, it has massively helped Wikipedia do Ruby deployments. So, thanks Carlhuda!

    -hampton.

  • Hey everyone,

    I totally understand that the current state of bundler (beta, heading to stable 1.0) is frustrating for early adopters. Carl, André and I take usability very seriously and definitely want to hear about specific usability problems you’re having as soon as possible.

    We know that bundler is still in beta, and very much appreciate your efforts in helping to ferret out both traditional bugs and usability bugs.

    In the meantime, you are certainly welcome to use a different solution. In Rails 2.3, you can still use the config.gem system if it’s working for you.

    In Rails 3.0 (which is also in beta), you can replace boot.rb (which is now only 8 lines) with any code that correctly sets up the load paths for Rails and any plugins you need. You can also replace line 6 of application.rb to require gems or plugins you are using any way you wish.

    For instance, you might use rvm gemsets, rip, or plain old rubygems to set up your load paths. This will likely expose you to a certain degree of manual dependency management, but you’re free to experiment with other solutions that work for you.

    If you’re interested in a particular feature and want to know when it’s likely to make it in, please feel free to check out our roadmap at http://github.com/carlhuda/bundler/blob/master/ROADMAP.textile. The roadmap also described any future breaking changes (which should be minimal) in some detail. In particular, build options is slated for 0.10, which should also improve common performance concerns and further streamline the workflow.

    • BJ Clark

      Yehuda,

      First, thanks for taking the time to respond.

      I’m not sure if I wasn’t clear, or what, but I’m fully aware of the roadmap. Here’s my point: If there had been a roadmap at 0.8, it wouldn’t have said “0.9: Remove –build-options and change the internal load path”. Just as you can’t know all the things that aren’t going to work to make 0.10 happen and 1.0 happen.

      Which leads me back to “A significant piece of Rails 3 is still in the “spike” phase”.

      The whole “You don’t have to use Bundler to use Rails 3” is a strawman and we both know it. “Replacing boot.rb” isn’t a viable, long term solution at this point. Replacing boot.rb is like saying you can use any ORM you’d like in Rails 2.3, something *you* have rejected for a long time.

      I really don’t want to make this into, or see why it should be, an us and them fight. We are trying to *help* you, but feeling nothing but rebuked.

      • Hey Bj Clark,

        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.

  • While I agree that Bundler is horribly unstable (I too have cried myself to sleep as things go horrifically wrong between patch versions), it is (as Andre said) not even 1.0.0 yet.

    No need to keep shooting the Bundler team down over beta software. The fact that so many people are prepared to waste so much time fighting with it is proof that is is sorely needed.

    Sit back, relax and let it mature. Then we can all live happily ever after.

  • Since Rails 3 doesn’t actually require bundler, can you please fix this error?

      ~:$ gem install rails --pre
    WARNING:  Installing to ~/.gem since /Library/Ruby/Gems/1.8 and
    	  /usr/bin aren't both writable.
    ERROR:  Error installing rails:
    	rails requires bundler (>= 0.9.2, runtime)
    
  • Pingback: Pat Maddox, BDDMF » Blog Archive » Disconnect()

  • Pat, that’s totally ridiculous. Rails 3 doesn’t require the Bundler any more than it requires ActiveRecord, or any of the other components that come with it by default but are optional.

    • It’s not totally ridiculous. I just copied and pasted the output from my Terminal.app.

      So here’s the deal:

      1. gem install rails *requires* bundler
      2. Installing bundler *requires* gem update to 1.3.6
      3. gem 1.3.6 sadly breaks other shit I have

      So it is really really really really fucking annoying to hear people tell me that Rails doesn’t require Bundler. Yes, I get that it may be configurable, or hackable, or whatever, but right now it’s a MASSIVE PAIN IN THE ASS.

      • Pat, you should not use `gem install rails` if you do not want to use Bundler. As you won’t use `gem install rails` if you do not want to install ActiveRecord, so you can use DataMapper.

        Why? The `gem install rails` is a pack with the defaults, so whoever is new to Rails can get a pack with the defaults without us asking them to make decisions about ORM or packaging system upfront (convention over configuration).

        If you want to choose your options, you should start it in the command line. 🙂

  • I’ve had some issues too. But keep in mind:

    * Bundler is in development, so expect some issues or constantly changing API
    * Rails is the same. Things change constantly.

    If you use either before release, you should expect these things.

    @andre, Rails 3 does require Bundler for install. But you can remove it. To reiterate what Wycatz said, the default boot file that relies on Bundler can be replaced to use your own package management (rip for example).

  • You said: ‘“You don’t have to use Bundler to use Rails 3? is a strawman and we both know it. “Replacing boot.rb” isn’t a viable, long term solution at this point.’

    You are wrong. config.gems was not a viable, long-term solution. Bundler is. Dependency management is a hard problem, and bundler solves it correctly, AND with a focus on long-term app stability.

    I know this because I created the next best solution – GemInstaller (4.5K downloads). GemInstaller is superior to config.gems because, like Bundler, it is NOT tied to Rails. Geminstaller is also inferior to Bundler for many reasons, but the most fundamental one is that Bundler RESOLVES and FREEZES your entire dependency graph. Before Bundler, people dealt with all those edge cases manually. Even the unresolvable ones, which Bundler now tells you about immediately when you change your config.

    Bundler is new, just like all of Rails 3. There is a detailed roadmap and bugs are being fixed steadily. Even with the bugs, Bundler is the RIGHT solution, and there is NOTHING superior.

    So, I’d suggest you apologize to Carl and Yehuda for this unnecessary little rant.

    Thanks,
    — Chad

    • Shenanigans.

      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.

    • Perhaps we should help BJ develop an apology. “Sorry your software breaks my shit repeatedly?”

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

  • Chad, you say that config.gems isn’t a viable, long term solution, that Geminstaller isn’t a viable, long term solution, and that Bundler will eventually be a viable, long term solution — and that “there is NOTHING superior”.

    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.

  • Steve Rowley

    I’m nobody in the Rails world, but it’s tough to disagree with the notion that Bundler doesn’t meet the popular standard of “beta” software. I think most people expect beta code to undergo repairs as opposed to overhauls, not unlike the merely minor fixes we’ve seen with the rest of the Rails 3 core components. Whether Bundler is “required” or not is beside the point; it’s a core, default component. To parrot others, ActiveRecord isn’t required either, but I wouldn’t blame people for being upset if ActiveRecord was getting overhauled again and again after the beta announcement.

    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.

  • Excellent points Steve Rowley. In the spirit of your comment, here’s my shot at giving useful analysis and alternatives.

    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

  • Pingback: Caffeine Driven Development » Blog Archive » L33t Links #85()

  • Ms. ZazzlePants

    Bundler…I think it’s sweet!

  • Pingback: From Bundler to Open and Inclusive Software Communities : Steven R. Baker()

  • Stephen Judkins

    It’s ironic that I found this post while looking to fix some pretty painful issues I’m having using Bundler, but now that I’m here I will attempt to defend it.

    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.