Fixed guard scroll causing engine yard deploy failure due to inconsistent gems between dev & prod

[allangrant]

The guard scroll put some code in the Gemfile like this:

require 'rbconfig'
HOST_OS = RbConfig::CONFIG['host_os']

group :development do
  case HOST_OS
  when /darwin/i
    gem 'rb-fsevent'
    gem 'ruby_gntp' if guard_notifications
  when /linux/i
    gem 'libnotify'
    gem 'rb-inotify'
  when /mswin|windows/i
    gem 'rb-fchange'
    gem 'win32console'
    gem 'rb-notifu' if guard_notifications
  end
end

This caused problems when deploying to Engine Yard (or any system with a different os than the development machine) because the expected gems weren't in the lock file.

This patch moves the switch to occur when the app is created. (A scroll is usually cast in the development environment, right?)
It only puts one set of gems in the gemfile and fixes Engine Yard deploy. Output in Gemfile (for a mac system):

gem "rb-fsevent", :group => :development
gem 'ruby_gntp', :group => :development if guard_notifications

[drnic]

I never saw this because I wasn't using notifications locally and had commented out those lines. I'll test this out for the next release. Thanks!

[thommahoney]

@allangrant, I'm confused about why this change actually fixes anything. There may be a better solution. Let's chat.

[allangrant]

@thommahoney Definitely open to better solutions. This change at least fixes the problem by making sure the Gemfile is interpreted the same way when it's read on production and in development that are different OS. With the switch on the operating in the Gemfile, it looks like Gemfile.lock hasn't been updated when Gemfile.lock is generated on a different operating system - because even gems that are only used in development are included in the lock file.