Alright, I just committed a change to Capistrano that makes it so you
can do:
default_environment["PATH"] = "/foo:/bar:/baz"
All environment keys 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 of environment variables is 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
-~----------~----~----~----~------~----~------~--~---
