Oh, and I should say: cap DOES have a -q flag, which suppresses all
but the most significant output. By default, cap is noisy.
cap -q some_task #- very quite
cap -v some_task #- slightly noisier
cap -vv some_task #- slightly noisier still
cap -vvv some_task #- noisiest (default)
- Jamis
On Dec 23, 2006, at 4:33 PM, wolfmanjm wrote:
sorry yes I can... here is an example whenI use deprec which uses
caprc... Notice the 8 lines of output after loading caprc. It happens
everytime, maybe there should be a -q that suppresses that although I
like the rest of the output capistrano gives.
loading configuration
/usr/lib/ruby/gems/1.8/gems/capistrano-1.2.0/lib/capistrano/recipes/
standard.rb
loading configuration /home/morris/.caprc
loading configuration
/usr/lib/ruby/gems/1.8/gems/deprec-1.1.0/lib/deprec/recipes/ssh.rb
loading configuration
/usr/lib/ruby/gems/1.8/gems/deprec-1.1.0/lib/deprec/recipes/svn.rb
loading configuration
/usr/lib/ruby/gems/1.8/gems/deprec-1.1.0/lib/deprec/recipes/ubuntu.rb
loading configuration
/usr/lib/ruby/gems/1.8/gems/deprec-1.1.0/lib/deprec/third_party/
mongrel_cluster/recipes.rb
loading configuration
/usr/lib/ruby/gems/1.8/gems/deprec-1.1.0/lib/deprec/third_party/
railsmachine/recipes/svn.rb
loading configuration
/usr/lib/ruby/gems/1.8/gems/deprec-1.1.0/lib/deprec/third_party/
railsmachine/recipes/apache.rb
loading configuration
/usr/lib/ruby/gems/1.8/gems/deprec-1.1.0/lib/deprec/third_party/
railsmachine/recipes/mysql.rb
loading configuration
/usr/lib/ruby/gems/1.8/gems/deprec-1.1.0/lib/deprec/recipes.rb
loading configuration ./config/deploy.rb
On Dec 23, 1:27 pm, Jamis Buck [EMAIL PROTECTED] wrote:
On Dec 23, 2006, at 2:03 PM, wolfmanjm wrote:
will you be able to disable the stdout? right now mikes patch
prints
out a lot of stuff as it loads all the things in .caprc, which
is kind
of annoying.I'm not sure what you mean? Mike's patch didn't
really have anything
special to do with writing diagnostic info. Can you be more specific?
- Jamis
On Dec 23, 8:15 am, Jamis Buck [EMAIL PROTECTED] wrote:
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
