Having to learn the ins and out of bundler `bundle exec, update, --without :darwin`.. just to use a package handler. I had growl_notify installed, and now we've forced our team to be mac only because we got tired of dealing with linux issues.

Ruby Debug is impossible to get working in 1.9.3. The maintainer of ruby-debug has gone AWOL so we're forced to deal with solutions like this http://blog.wyeworks.com/2011/11/1/ruby-1-9-3-and-ruby-debug that don't work within bundler or a team environment.

1.9.2 + Rails 3.x is attrociously slow (30+sec). With falcon (a very unstable ruby hack) the startup speed goes to 10seconds. But 10sec is still way too slow

Sorry, it sounds bad when I just rant. In the grand of scheme of things, Rails makes me more productive as a web dev than I ever thought possible. It's just easy to pull out the daily frustrations and complain. I've been trying to help fix these issues but they are so dependent on a web of gem authors, and core ruby fixes that it takes an extraordinary amount of time.

I'm almost to the point where I think things need to be fixed top down. Matz needs to take control and try to make stuff not suck as soon as possible. Since he's working for Heroku now, it's in his best interest to push the platform and keep new users engaged.

> Ruby Debug is impossible to get working in 1.9.3.

Ruby 1.9 ships with a debugger:

    require 'debug'

Besides, I've often find Pry way more useful: https://github.com/pry/pry

Thanks for the heads up. I've searched far and wide to find any sort of docs for the built in debugger. ruby-debug was incredibly easy to use. require 'debug' sets a breakpoint, but I cant figure out any way to interact with it.

I use pry, however I've found it's very unreliable for stepping into shoulda tests, and often it errors out. I haven't been able to find stable alternatives to the most common ruby-debug commands 'l', 'e', 'n' and 'c'.

You don't have to use Bundler. Just delete the Gemfile and manage the dependencies yourself.

The problem is that there's no third option- something to manage dependencies that's not bundler. We all want and need dependency management, but bundler should not be the One True Solution.

I've used Isolate[1] pretty happily on a few things (command-line tools and/or Sinatra apps). I haven't tried it with Rails, so I can't speak to how well it works in that context. But the readme's first example is Rails, so it's worth a look if you really want an alternative.

[1] https://github.com/jbarnette/isolate

Hadn't seen Isolate before- looks awesome. I'll try it out. Autorequire is one of my biggest complaints against bundler.

Is autorequire even a real problem? You can quite easily put your gems in a separate group if you want to manually require them. Installing is another issue, that is opt-out, but I don't see the install process as the real bottleneck.

Write your own? I'm sorry but if Bundler doesn't solve your problem (or introduces other problems) either try and fix those issues OR write your own dependency management lib.

The unfortunate reality about writing your own new Bundler is that you'll inevitably end up rewriting Bundler. Isolate is basically just a mini-Bundler with a different (arguably simpler) storage location, but the storage location is really not where the complaints about Bundler are coming from.

Rewriting things just to shed complexity or "bloat" will often just put you in a position where your library just can't do things it will need to do, and then you end up rewriting those things and adding back the complexity. It's the circle of life. Lack of SCM support in Isolate is a good example-- I'm pretty confident that Bundler's support of git is heavily used and taken for granted, but if you were to rewrite or use a simpler dependency manager, you're throwing this out.

This point feeds back into the larger issue of Rails vs. Node, I think. Rails ended up with all the complexity it has now because it was [mostly] necessary-- not all of it was, but much of it was. The idea that you're somehow liberating yourself by shedding complexity is often just the short-sighted pleasure of running faster test suites. And it's usually followed by a little bit of claustrophobia when you realize you can't do X, Y, or Z anymore. Wait until the claustrophobia kicks in, because it will. And the solution to this claustrophobia? More cowb-- complexity.

I agree. I just hate to see this ― "zomg bundler sucks at <some feature usually speed>! I hate using it! It has to be fixed for me!"

Any open source project needs help. The maintainers of Bundler have 200+ issues on the issue tracker. If people could help them replicate and confirm issues, write failing tests and if possible write patches ― it would do a world of good. But instead it's EASIER to complain and whine. So...

And discussions like this, raising awareness and exchanging ideas, are a part of getting the problem fixed.

The correct place for these discussions is on the issue trackers & mailing lists of Bundler.

getting ruby-debug to work with 1.9.3 was one of the first things I done after trying 1.9.3.. it wasn't hard or time consuming, I don't even remember what was the fix.. so I don't get this complaints...

I don't have bundle exec issues...

time rake environment takes 4 seconds(1.9.3, 3.2)

I agree with a lot of things in the article, but I don't have the issues a lot of people are complaining here..