I found a workaround for my particular case. Before the call to
CLI::execute! I put
Capistrano::Configuration::Namespaces::Namespace.class_eval { undef :symlink }
This works since I know I'm never trying to call FileUtils#symlink on
the Namespace object. It's not a super satisfying solution, for two
reasons: a) it's not generalizable; if I want to call a task install,
I'll get another FileUtils collision, and b) it breaks the contract
with rake. But I can live with those for this project.
Sarah
On Wed, Apr 1, 2009 at 5:45 PM, Jamis Buck <[email protected]> wrote:
>
> Rake doesn't add it to Capistrano, it adds it to Object, so that you can
> call FileUtils.symlink without the FileUtils prefix. It's pretty
> unfortunate, and I don't know of a good way to work around it, sadly.
>
> - Jamis
>
> On 4/1/09 5:41 PM, Sarah Mei wrote:
>> The operations folks at my company would like to have Capistrano and
>> all its related gems contained in the svn trunk of the Rails app. So
>> in my local copy, I installed all the gems in vendor/gems using gem
>> install. (capistrano, echoe, highline, net-scp, net-sftp, net-ssh,
>> net-ssh-gateway, and rubyforge were installed.)
>>
>> I copied the cap executable from /usr/pkg/ruby/bin/cap and modified it
>> to use vendor/gems as the gem path. Using that, I can run cap deploy
>> just fine from the command line. I can tell it's running the version
>> in vendor/gems. So far so good!
>>
>> However, in my Rails app I also have a rake task that does some
>> parameter munging and then calls Capistrano in code via the
>> Capistrano::CLI library. When I run that, executing the equivalent of
>> a cap deploy, it fails to load the deploy recipes. This happens in the
>> first line of Capfile - it never even gets to my deploy.rb. The error
>> is:
>>
>> defining a task named `symlink' would shadow an existing method with that
>> name
>>
>> I tracked it down to lib/capistrano/configuration/namespaces.rb. While
>> defining the tasks in the deploy recipe, Capistrano seems to think it
>> has a method called "symlink" that the symlink task will collide with.
>> I had a look at self.ancestors inside the call that's throwing the
>> error - and it's right. One of its ancestors is FileUtils, which has a
>> symlink method.
>>
>> Rake seems to be adding this. When I run the same code via a
>> command-line cap deploy, self.ancestors does not include FileUtils.
>>
>> Any ideas why (or how?) Rake is adding this stuff to the Capistrano
>> classes? I may just end up calling the command line from the Rakefile
>> instead of doing it in code, but that's a little ugly. (Well, not like
>> what I'm doing now isn't...) Here's how I do it in code:
>>
>> def cap(*parameters)
>> require 'rubygems'
>>
>> Gem.use_paths(Gem.dir, ["#{RAILS_ROOT}/vendor/gems"]) # Point to
>> frozen cap version
>> Gem.refresh # picks up path changes
>>
>> gem 'capistrano', '=2.5.5'
>> require 'capistrano'
>> require 'capistrano/cli'
>>
>> unless ENV['REVISION'] then
>> raise "Please set REVISION; exiting..."
>> end
>> ENV.delete 'REVISION' if ENV['REVISION'].upcase == "HEAD"
>> parameters<< ['-S', "tag=#{ENV['TAG']}"] if ENV['TAG']
>> parameters<< ['-S', "revision=#{ENV['REVISION']}"] if ENV['REVISION']
>> parameters<< ['-S', "target=#{ENV['TARGET']}"] if ENV['TARGET']
>> parameters<< '-q' if ENV['QUIET']
>> parameters.flatten!
>> puts "PARAMETERS:"
>> puts parameters.map{|p| p.to_s}
>>
>> Capistrano::CLI.parse(parameters.map { |param| param.to_s }).execute!
>> end
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
