Mike,
Alright, this finally made it in (as of revision 5774). I didn't use
your implementation directly, though, as there were a few issues I
had to think about.
Here's how dotfiles work in edge capistrano:
* The dotfile, by default, is called ".caprc" and will be searched
for in your home directory. On Unices, this is the ENV["HOME"]
variable. On windows, it is "#{ENV["HOMEDRIVE"]}#{ENV["HOMEPATH"]}".
The environment is searched in that order (so if you have HOME set on
Windows, it will be used), and if none is found the root directory is
used.
* You can override the path to the config file via the -c switch:
"cap -c /path/to/.customrc ..."
* You can specify that you don't want to use the config file at all
via the -x switch: "cap -x ..."
* The file will be loaded immediately after the "-S" options are
processed. Thus, variables you set via -S will be available to
the .caprc stuff.
The major difference between the patch you submitted and the way I
implemented it is that the .caprc will always be loaded, whether or
not other recipe files are specified. (As I mentioned above, you can
skip the config loading with -x.)
Thanks for the idea, Mike, and sorry that took so long to get into
trunk!
- Jamis
On Nov 21, 2006, at 6:02 AM, mbailey wrote:
> I'm loving capistrano. I'm using it for sysadmin tasks as well as
> rails
> deployment.
> I want to be free to use it from whichever directory I happen to
be in
> and still have access to my favourite recipes. I want to be able to
> run
> commands on server groups that span projects. I want to use recipe
> gems
> that other developers may not have on their system so requiring
them
> from a shared deploy.rb may not be appropriate.
> Below is a small patch that loads the contents of ~/.caprc before
> loading the default recipe file (usually config/deploy.rb).
> An example of my .caprc is below:
> # RECIPE GEMS - the easiest way I can think of to enable recipe
gems
> require 'railsmachine/recipes'
> require 'deprec'
> # SSH OPTIONS - only set this once on workstation rather than on
each
> project
> ssh_options[:keys] = %w(/Users/mbailey/.ssh/id_dsa)
> # ROLES - useful for getting cap shell on horizontal slice of
systems
> # enables commands like this to span projects when
> not in
> a project dir:
> # export ROLES=scm && cap -v shell
> role :scm, 'scm01', 'scm02', 'scm03'
> role :rails, 'r01', 'r02', 'r03', 'r04', 'r05'
> role :db, 'db01', 'db02', 'db03', 'db04'
> Does it look acceptable to go into Capistrano? The main benefit I
> could
> see is making
> it more convenient for users to run 'gem install <recipename>' and
> then
> update their
> ~/.caprc to make the recipes available.
> thanks,
> Mike
> inum:~/work/capistrano/lib/capistrano mbailey$ svn diff
> Index: cli.rb
> ===================================================================
> --- cli.rb (revision 5603)
> +++ cli.rb (working copy)
> @@ -289,6 +289,10 @@
> end
> def look_for_default_recipe_file!
> + # load overridable user defaults (if present)
> + if File.exist?(caprc = File.join(ENV['HOME'],'.caprc'))
> + @options[:recipes] << caprc
> + end
> DEFAULT_RECIPES.each do |file|
> if File.exist?(file)
> @options[:recipes] << file
> inum:~/work/capistrano/lib/capistrano mbailey$ rake test
> (in /Users/mbailey/work/capistrano)
> /usr/local/bin/ruby -Ilib -rubygems
> "/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/
> rake_test_loader.rb"
> "test/actor_test.rb" "test/command_test.rb"
> "test/configuration_test.rb" "test/ssh_test.rb" "test/scm/
cvs_test.rb"
> "test/scm/subversion_test.rb"
> Loaded suite
> /usr/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/
rake_test_loader
> Started
> ...................................................................
...
> ......................
> Finished in 0.039947 seconds.
> 92 tests, 192 assertions, 0 failures, 0 errors
