Hi,
First, thanks for adding the default_environment[], my hosting
company
has the SSHD PermitUserEnvironment disabled, so I'm glad to see the
new
feature in capistrano 2. I believe, however, there is a bug in it.
Capistrano tries to run commands of the form
A && B && C
but the environment variables are only set for the first element of
the list.
If I set 'default_environment["PATH"] = "/home/my-user/bin:/usr/
local/bin..",
then Capistrano prefixes the command with the env:
PATH=/home/my-user/bin:/usr/local/bin.. A && B && C
The bug is that only A's environment is set. B and C run in the
standard
environment (this is the way the shell is supposed to work). Each
element of the list must have its environment set:
PATH=/home/my-user/bin:/usr/local/bin.. A &&
PATH=/home/my-user/bin:/usr/local/bin.. B &&
PATH=/home/my-user/bin:/usr/local/bin.. C
Here is a test case, based on the actual commands capistrano 2 is
trying
to execute:
default_environment["PATH"] = "/home/my-user/bin:/usr/local/bin:/
bin:/usr/bin"
default_environment["PYTHONPATH"] = "/home/my-user/lib/python"
task :does_not_work do
# The original capistrano command string fails, as the second
# invocation of hg fails with:
# ** [out] sh: hg: command not found
run "hg clone --noupdate /home/my-user/my-repository /home/my-
app/releases/20070619043329 && hg update --repository /home/my-app/
releases/20070619043329 --clean 62fc5ca5eaa4 && (echo 62fc5ca5eaa4 > /
home/my-app/releases/20070619043329/REVISION)"
end
task :does_work do
# If I break the command up into two separate runs, then it
works
# (the third clause does not depend on the default_environment
setting)
run "hg clone --noupdate /home/my-user/my-repository /home/my-
app/releases/20070619043329"
run "hg update --repository /home/my-app/releases/20070619043329
--clean 62fc5ca5eaa4 && (echo 62fc5ca5eaa4 > /home/my-app/releases/
20070619043329/REVISION)"
end
On May 31, 8:09 pm, Jamis Buck <[EMAIL PROTECTED]> wrote:
> Alright, I just committed a change to Capistrano that makes it so you
> can do:
>
> default_environment["PATH"] = "/foo:/bar:/baz"
>
> Allenvironmentkeys that you put in the default_environment hash
> will be applied to every run() and sudo() call. If you specify
> the :env key to run() or sudo(), it will be merged on top of
> default_environment, so if (for example) you specify "PATH" via :env,
> it will override the "PATH" you specify via default_environment.
>
> Thanks for the idea, Chris!
>
> - Jamis
>
> On May 31, 2007, at 7:04 PM, mh wrote:
>
>
>
> > Same problem here. Lack ofenvironmentvariablesis impacting the
> > ability to use Cap to manage a Rails app on Ubuntu using MS SQL Server
> > via unixODBC.
>
> > On May 22, 12:07 am, Chris Roos <[EMAIL PROTECTED]> wrote:
> >> I know (from googling) that some other people are having this same
> >> problem, so does anyone (Jamis) have any comments?
>
> >> Chris
>
> >> On May 15, 5:15 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> >> wrote:
>
> >>> Hi,
>
> >>> I've been playing with Capistrano 2 (which looks great) for the last
> >>> couple of days and have been running into problems caused by the
> >>> 'empty' defaultenvironmenton theremotehost/s. My main problem is
> >>> that the PATH is not set correctly. I can solve the problem for svn
> >>> (bysettingscm_command variable) and rake (bysettingrake variable)
> >>> but not for arbitrary commands. A little googling seems to suggest
> >>> that I could edit my /etc/sshd_config (enabling
> >>> PermitUserEnvironment)
> >>> and thensettingmyenvironmentvariablesin ~/.ssh/environment.
> >>> Alternatively, I can symlink the binaries to something like /bin
> >>> or /
> >>> usr/bin. None of these approaches seem particularly appealing so I
> >>> started digging into the code a bit. I noticed that you are able to
> >>> initialize a Command with options that includeenvironmentvariables
> >>> (by supplying {:env => {ENV_VAR}}, which are parsed by
> >>> Command#extract_environment). I also noticed that the only place a
> >>> Command is constructed is in Invocation#run. Although
> >>> Invocation#run
> >>> can take options that include theenvironmentvariables, there doesn't
> >>> seem to be any way to specify them for the default tasks (in
> >>> deploy.rb). I'm still pretty new to Capistrano so may have missed
> >>> something obvious here...
>
> >>> Anyhoo. I was thinking that we could maybe have a special variable
> >>> called, something like, env_vars, that was used as a default in
> >>> Invocation#run. In fact, adding these two lines to the beginning of
> >>> the run method (combined withsettingthe env_vars variable in my
> >>> Capfile) seem to have the desired effect.
>
> >>> # invocation.rb
> >>> def run(cmd, options={}, &block)
> >>> env_vars = { :env => fetch(:env_vars, {}) }
> >>> options = env_vars.merge(options)
>
> >>> # Capfile
> >>> set :env_vars, { 'PATH' => '/opt/local/bin:/usr/local/bin:$PATH' }
>
> >>> Being new to Capistrano, I'm not sure whether a) this is already
> >>> implemented and I missed it, b) this is intentionally not
> >>> implemented,
> >>> c) this would be the right way to go about implementing it.
>
> >>> I'd be happy to strap some tests around this change if it feels like
> >>> the correct place for it. Alternatively, I'd be happy to submit an
> >>> alternative patch if you had some strong feelings about how it
> >>> should
> >>> be implemented (if at all), and can give me some pointers.
>
> >>> Cheers,
>
> >>> Chris
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
