Great ideas Vassilis, I like the 3rd argument to set, and how the block syntax would work, and I agree on not needing a way to replicate `-s`, although I don't think env variables are the solution (my general rule of thumb, is that if you HAVE to set the env var, you are doing something wrong, they should be for easy tweaks to otherwise functioning software config)
Regarding the order of lookup for variables, I agree that it's sane and clean now, and I don't really want to make it messier, but I'd like to better understand Clinton's usecase before dismissing the idea all together. Lee Hambley -- http://lee.hambley.name/ +49 (0) 170 298 5667 On 17 October 2013 13:01, Vassilis Rizopoulos <[email protected]>wrote: > I don't think this is a cap issue. > > We have several ways to pass parameters into tasks. > Let's take the obvious two offered by rake: task arguments and environment > variables. > Then we have the cap's settings system which works quite well and has a > clear override sequence (global to stage to task, or am I mistaken?) > > With rake I have very often used the simple trick of creating my own > configuration class that reads from a config file and is initialised at the > top of my rakefile. > Exactly the same code works with cap, no problems (one of the reasons I > loved the change to rake-based cap) > > Actually all of my rakefiles nowdays look like this: > > require 'helpers' > setup_environment(__FILE__) <---- configuration is read in here > require 'tasks' > > and all my code is nicely gemified somewhere else. > > Which configuration file to read is then passed via an environment > variable. This works intuitively on the command line (adding CONFIG=foo is > very obvious) but it also has the added advantage of allowing us an easy > way to set a default. > > I think we might have more luck talking about how to think in terms of > deploy/stage/task and what belongs where and how we can leverage Ruby to > make it more flexible without adding more concepts and/or abstractions to > core cap. We then can talk about extensions to core cap in the form of gems. > > I must say I like the > > set :foo,ENV['FOO'] > > fetch(:foo,"bar") > > construct but it will get tiresome quick if we have to sprinkle the > default value around with every fetch. How about having a set version with > 3 params > > set(setting,calculator,default) > > That way we can write set :foo,ENV['FOO'],"foo" > > Which would work the same with a block version of set > > set(setting,&block) --> set :foo { ENV['FOO'] || "foo" } > > I'll stop thinking out loud now > Cheers, > V.- > > -- > -- > * You received this message because you are subscribed to the Google > Groups "Capistrano" group. > * To post to this group, send email to [email protected] > * To unsubscribe from this group, send email to > [email protected] For more options, visit this > group at http://groups.google.com/group/capistrano?hl=en > --- > 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 [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- -- * You received this message because you are subscribed to the Google Groups "Capistrano" group. * To post to this group, send email to [email protected] * To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/capistrano?hl=en --- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
