Capistrano 3.0: server deploy complains about gemfile.lck on conditional gemfile lines specific for development computer:

[Jay Thompson]

Versions:

• Ruby 1.9.3
  
• Capistrano 3.0.1
  
• Rake / Rails / etc rails 3.x
  

Platform:

• Working on maxos
  
• Deploying to. debian or fedora
  

Logs:

• Please past logs (as completely as possible to a 3rd party pasting service such as pastie.org)

....git checkout and deploy steps and then I get:

EBUG [5f99ef42]     You are trying to install in deployment mode after changing
DEBUG [5f99ef42]     your Gemfile. Run `bundle install` elsewhere and add the
DEBUG [5f99ef42]     updated Gemfile.lock to version control.
DEBUG [5f99ef42]    
DEBUG [5f99ef42]     You have deleted from the Gemfile:
DEBUG [5f99ef42]     * rb-fsevent
cap aborted!
bundle stdout: Nothing written
bundle stderr: Nothing written
/usr/local/rvm/gems/ruby-1.9.3-

Files:

• Capfile default
  
• deploy.rb default
  
• Stage files (production.rb, staging.rb) vanilla

I have the following gemfile line in a test group

    group :test do

   gem 'rb-fsevent', :require => false if RUBY_PLATFORM =~/darwin/i

   end

Does somebody advise the appropriate workaround for this situation where the conditional seems to create a Gemfile.lck that includes the OSX specific gem, and the production server does not require it, and errors on the bundle?

[Lee Hambley]

I think your mistake is that with this line of code the gem def doesn't happen on non Darwin hosts, bundler provides a way to filter gems by platform.

Sent from my Nexus 4.

--
You received this message because you are subscribed to the Google Groups "Capistrano" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capistrano+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/capistrano/45a4bc69-34e2-4efa-abcd-469b3ee3785e%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Lee Hambley]

See the PLATFORMS section http://bundler.io/v1.3/man/gemfile.5.html

Sent from my Nexus 4.

[Jay Thompson]

Thanks, Herr Hambley, for quick response,

Maybe I misunderstand your answer, but I think I understand the conditional bundle. On my dev system, I bundle and gen up a Gemfile.lck which has rb-fsevent based upon the local OS and commit to git.  But when I deploy I get the error--as the lockfile is referring to a gem that isn't required on the server.   If I comment out the conditional line in the bundle, the deploy executes okay.  So I guess my options that I can think of include:
git hook
rake task to temporarily comment out the offending line in Gemfile, bundle and git commit
remove the offending gem
server task that reissues the bundle, or suppresses the error somehow


and I so much appreciate your work-(might I suggest adding filenames to each of the code fragment examples on https://github.com/capistrano/capistrano/blob/master/README.md and updating your copyright dates to 2014)  I would do a pull request myself, but I don't know if I would be correct.

[Lee Hambley]

Hey Jay,

The problem is that the construct you use `gem 'foo' if <something>` only defines the Gem if that conditional returns true. Thus your Gemfile.lock looks different depending what platform it is built on.

If the Gemfile.lock does not match the Gemfile, then bundler will assume you are in dev mode, rebundling, or changing dependencies or something, and will forbid what you are trying to do.

If you use the Bundler (man (5) bundler) PLATFORMS option, then the Gemfile.lock and the Gemfile will always match (and your fs-event gem will always be defined)

In this model the Gems will however be installed according to the current platform.

Lee Hambley

--

http://lee.hambley.name/

+49 (0) 170 298 5667

--

You received this message because you are subscribed to the Google Groups "Capistrano" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capistrano+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/capistrano/4e7ebf33-31f5-45e7-89ab-2363b19eab00%40googlegroups.com.

[Jay Thompson]

My problem actually was a bit more fundamental/stupid: I had rerun cap setup to increase add some stages, and when deploy.rb got rewritten, I had edited incorrectly  pointing to a scratch repo where the Gemfile.lock was stale.  (sigh).

Thanks Lee,
Regards,