I'm not sure why you need to use a lambda then force it to memoize the return.
Why doesn't this work for you?
set(:user) {Capistrano::CLI.ui.ask(Your SSH User name : )}
on first use it will ask; then return the same value every time it's used
thereafter
And on scoping global variables.
On Nov 16, 2011, at 1:15 AM, Donovan Bray wrote:
I'm not sure why you need to use a lambda then force it to memoize the
return.
Why doesn't this work for you?
set(:user) {Capistrano::CLI.ui.ask(Your SSH User name : )}
on first use it will ask; then return the same value every time
Did you come up with some way to fork multiple parallel deploys, of
multiple projects?
It sounds very much like you are doing something very wrong.
--
* You received this message because you are subscribed to the Google Groups
Capistrano group.
* To post to this group, send email to
On Nov 16, 2011, at 9:35 AM, Lee Hambley wrote:
Did you come up with some way to fork multiple parallel deploys, of multiple
projects?
It sounds very much like you are doing something very wrong.
no question about it - I am doing something very wrong ;-)
I am working on meshing it
But eventually were you able to get it down to a one-liner shell command,
or is it still two deployments?
You mentioned `forking` - if you were really using fork, you would inherit
any pre-set variables, but when they're not pre-set, then you would have to
enter them into each individual child
Based on what I saw he is not forking; he is creating a sub shell via a
system() call; so there will be no sharing of anything from the run time
parent cap.
Acknowledged, bit of a shame, would be possible to set up the variables,
fork and load the individual depoys, I expect… but honestly
On Nov 16, 2011, at 10:52 AM, Lee Hambley wrote:
Based on what I saw he is not forking; he is creating a sub shell via a
system() call; so there will be no sharing of anything from the run time
parent cap.
Acknowledged, bit of a shame, would be possible to set up the variables, fork
duh recipes/deploy.rb (right near the top too...)
def _cset(name, *args, block)
unless exists?(name)
set(name, *args, block)
end
end
I can change them until the cows come home but once they are set during a run,
they're not going to change unless I hack capistrano itself. ;-(
Hah, if you hadn't found the difference and posted I was going to set you
straight.
_cset is a method to do a conditional set. It's used for ensuring a safe
default value is present for a capistrano built in. Theres very few legitimate
reasons you would need/want/benifit from _cset in your
