Comments on: What’s New in Bundler 1.0.0.rc.1

By: Nathan B

Nathan B — Tue, 01 Mar 2011 03:38:10 +0000

@Spencer, Bundler already has this built in.

You can put your gems into groups, such as :development, :test, :cucumber. When you run bundle install on your production server, you just run “bundle install –without cucumber development test”, and it won’t install any gems you have put in those groups.

By: Spencer Dillard

Spencer Dillard — Thu, 16 Sep 2010 18:58:43 +0000

I’ve been struggling with all the dependencies I have in development that I don’t really want on my production server (spork, cucumber, etc.). I was thinking I could create a Gemfile.development and Gemfile.production that would really server as templates for developers, then have a Gemfile.lock.development and Gemfile.lock.production. When a developer is adding a gem for production use, they would just copy the Gemfile.lock to Gemfile.production. On deployment, we would copy the Gemfile.production to Gemfile and likewise with the .lock file. I realize it’s a bit of a pain, but I can’t come up with a better way to avoid installing lots of things that aren’t needed. Comments or suggestions?

By: David Greaves

David Greaves — Sat, 07 Aug 2010 12:05:54 +0000

So… if you’ve recently run a sudo (or if you have NOPASSWD in sudoers) then bundler will casually grab root to install downloaded gems.

Not clever.

bundler should not take sudo without explicitly asking or without a –sudo option.

By: Austin Bales

Austin Bales — Sat, 07 Aug 2010 06:33:55 +0000

Wow. I’ve read numerous “Getting Started” posts for bundler, and this is the first time I’ve finished and thought to myself, “Wow that seems incredible easy and useful.”

Thanks.

By: Libo Cannici

Libo Cannici — Fri, 06 Aug 2010 16:12:11 +0000

I am deploying via Capistrano with a user who cannot sudo. I really have big problem deploying and installing the gem with native extensions.

The gem installing script tries to do something like
make install
/usr/bin/install -c -o root -g wheel
..and it crashes.

In the past I was managing the native extension gem separately via puppet. But now I don’t know what to do.

Should I start deploying with a user who can sudo? It sounds bad!

By: Mclark

Mclark — Sat, 31 Jul 2010 16:03:02 +0000

I needed to uninstall bundler-1.0.0.beta.5 before rc.2 would cooperate. It was loading Thor out of the beta.5 gem, and that made the resolver unhappy. With beta.5 gone, all is right with the world again.

http://gist.github.com/502312

By: Lee Hambley

Lee Hambley — Wed, 28 Jul 2010 17:04:43 +0000

Great news that things are slowing down around here! I wanted to ask what is your proposed solution to comitting the Gemfile.lock – which often contains group(:test) dependencies (at least on developer workstations) when moving to production, I have seen this cause problems.

By: mateo

mateo — Wed, 28 Jul 2010 03:49:22 +0000

I’ve made a gist with capistrano config code that follows the deployment advice in the post; feel free to use and improve:

http://gist.github.com/493313

By: Loren Norman

Loren Norman — Tue, 27 Jul 2010 15:25:06 +0000

I’ve been using Rails 3 for a little over a month now, and I can happily say that Bundler 0.9 has been a massive time-saver and a huge productivity win. Bravo! This is NOT a trivial problem and Bundler is amazingly elegant.

The issue I want to bring up is the behavior of ‘bundle install [path]‘. The behavior of ‘remembering’ this path, while sensible, can really lead to some surprises.

We had a new Ruby developer (indeed, we are ALL new Bundler users) inadvertently use this command when trying to install a gem directly, thinking he needed ‘bundle install [gem_name]‘. Of course, this appears to work and one goes about their business, only later finding a [gem_name] directory in the project root full of gem directories. This is downright spooky!

The problem is exacerbated when using rvm (rapidly becoming a Ruby best-practice) and by a lack of documentation. Writing the BUNDLE_PATH variable to [project_root]/.bundle/config (which shadows the environment var that rvm correctly but ineffectually sets) doesn’t seem to be mentioned anywhere, indeed, I can’t find ANY mention of this config file and its options anywhere on gembundler.com!

Solutions:
- I’d like to see the ‘bundle install [path]‘ broken out into a separate command. I feel like it violates ‘least surprise’ to have the normal, run-of-the-mill ‘install’ command change global state. I’m flexible on this part, though, since it is certainly learnable.

- Documentation in 2 places (this is a must):
1) on the page describing ‘bundle install’ (http://gembundler.com/v1.0/bundle_install.html), where it says “Further bundle commands or calls to Bundler.setup or Bundler.require will remember this location” should clearly reference the mechanism it uses to remember the location: the config file and accompanying option.

2) a dedicated page for the config file. Where does it live? What options are there? When should I make changes to it and why?

- Finally, I’d love to see a writeup on using Bundler with rvm. The two clearly have some overlap and I’d like to know the best practices when using them together. rvm silos gems for different Ruby versions, but it also provides gemsets which allow you to further silo your gems. Which responsibilities fall into the realm of rvm, and which are better left to Bundler’s formidable functionality?

Thanks again, Yehuda. I’ll be happy to contribute some of this, but I wanted to give you the chance to tell me I was wrong, first!

By: Christoph Olszowka

Christoph Olszowka — Tue, 27 Jul 2010 11:46:29 +0000

Thanks Yehuda!

I thought it was worth pointing out that when running ‘bundle install’ for the first time on the RC (was using the latest beta prior to that), it will actually do a “bundle update”. This has happened for me at least, using a Rails 3 project with Haml 3.0.13, which has been updated to 3.0.14. This does not seem to be reproducible afterwards, bundle update and bundle install worked just as smoothly as you described it here.

@bryanl: Seems to me some kind of platform-based dependency block in addition to groups might make sense?