Make bundler use different gems for different platforms

Question

I\'m working on upgrading one of our Rails 2.3.8 apps to Rails 3, and have run into an annoying problem with bundler and deployment. I develop the application on a Windows m

Answer 1

You can do something like this:

platforms :ruby do
  gem "sqlite3-ruby", :require => "sqlite3", :group => [:development, :test]
end

platforms :jruby do
  gem 'activerecord-jdbc-adapter', :require => false
  gem "jdbc-sqlite3", :require => false
end

Btw, you should put your Gemfile.lock into the version control because this way all machines will run the application with the same gems versions.

Answer 2

Our engineers at Engine Yard have submitted a patch to Bundler to address this issue and unfreeze the gems if on a different platform. We've been having the same problem with many Windows trying to deploy after running through the RailsInstaller Demo Tutorial. The best fix we've found is to perform the following:

1. bundle install like normal on your development machine
2. Go through the Gemfile.lock and if there are any lines with -x86-mingw32, remove that part.
   • bcrypt-ruby (3.0.1-x86-mingw32) becomes bcrypt-ruby (3.0.1)
3. Add ruby under the 'Platforms' section in the Gemfile.lock
4. Make sure to explicitly specify the needed gem in the Gemfile with the platform flag. (Not sure if this is needed but it doesn't hurt)
   • In Gemfile: `gem 'bcrypt-ruby', '~> 3.0', :platform => 'ruby'
5. bundle install again which will keep the bcrypt-ruby (3.0.1) line and add in bcrypt-ruby (3.0.1-x86-mingw32) again.

If you're curious about the Bundler patch, you can get notifications at https://github.com/carlhuda/bundler/pull/1451

Hope this helps anyone still looking for answers.

Answer 3

I've ran into this issue before, and using the mysql2 gem does indeed fix the problem. I know that's not the answer you're looking for, but combine that with Diego's answer and you're golden.

Answer 4

I think the issue is that the mysql gem doesn't properly discover the needed headers. You can fix this by moving over to using the mysql2 gem, you'll just have to update your database adapters in database.yml for ActiveRecord integration.

Additionally, you can pass build flags to C extending gems if absolutely necessary:

bundle config build.mysql --with-mysql-config=/usr/local/mysql/bin/mysql_config.

Answer 5

This is a known issue in Bundler. The workarounds are either:

• Generate a Gemfile.lock on a system similar enough to your production environment that you get results that match your production platform. Effectively, that means you can only generate the Gemfile.lock file on Windows if your production system is Windows.
• Don't commit a Gemfile.lock file at all, and determine dependencies on the production machine at deploy time (bundle install without --deploy). While not recommended in general, this is an often-used workaround until the bug is fixed. For example, this is the recommended solution offered by Heroku.
• Switch to JRuby, which would have the same platform string across both Windows and Linux (java). I don't recommend this seriously, but I believe it would fix the problem.
• Fix the problem in the Bundler source code, i.e., help the Bundler team fix the bug. :)

Answer 6

I have a similiar problem. I would like to be able to write something like this in my Gemfile:

platforms :ruby do                      # linux
  gem 'nokogiri', "1.5.0.beta.2" 
end

platforms :mswin do
  gem 'nokogiri', "1.4.4.1" 
end

But, bundler tells me I am not allowed. So, my workaround, that works in this specific case is to point out a range of versions:

gem 'nokogiri', ">= 1.4.4.1", "<=1.5.0.beta.2" 

Which - at the moment - give the 1.4.4.1 version on my Windows computer and 1.5.0.beta.2 on my linux computer. Maybe it is possible for you to write a similiar ugly workaround ;-)