Use Bundler.setup Instead of Bundler.require

In a language with a more rigid module system I'd agree with this, but Ruby's is really problematic for this sort of thing. Your requires will eventually cease to be documentation as they go stale, and you'll almost certainly accidentally use a dependency you don't require. All of this results in Weird Dependency Failures At A Distance.<p>If there's one thing I wish Ruby would adopt from python it's the import namespace system. Then this kind of proposal would become more practical.

Wow, I'm always excited to see Rubyists promoting things being explicit in code. That's my primary gripe with Ruby projects, too much magic fairy dust and freebies that generates complexity. I'll keep this tip in mind when I play around w/ Rail/Grape next time.

I'm not sure that there's really any way to give a firm recommendation either way here. You can, after all, simply add<p><pre><code> :require =&#62; false </code></pre> to any gems which you don't want to require with Bundler.require.<p>&#62; Manually requiring dependencies at the top of every file very explicitly tells you and anyone else exactly what dependencies that file has.<p>While I don't disagree with this statement, I don't really know of any way to enforce it (certainly using Bundler.setup won't do so). You're always going to have everything that has been required elsewhere "pre-required" for you. I'll often start out explicitly requiring everything that a file needs when I start a project, and then end stopping when I look back at some file and notice that it lacks require statements for half the stuff it needs.

Another thing to consider is thread safety. "require" is not thread safe, so if your app is multi-threaded, it's actually a good idea to load everything up front. Granted, you can still do this with manual requires, but Bundler.require does that job for you pretty nicely.

If you subscribe to the philosophy that every line of code is a liability, which I do, this really hits home.