Re: [galaxy-dev] [galaxy-user] Galaxy does not find my executables
Florent Angly wrote:
I understand that it is best to flow with the logic of the
underlying OS and not too make too many platform-dependent
assumptions about what files should be read.
Perhaps, it seems like the best way to go would be to have a setting
in universe_wsgi.ini to specify a file to read additional
environment settings from? For example, in my case, I would add a
line like:
source_environment_from = '/Users/galaxy/.profile'
I'd rather not read from the config file over on the cluster when we're
just running basic tools, but how about a default of '~/.galaxy_env' or
'/path/to/galaxy-dist/env.sh', and can be overridden with the file
pointed to by '$GALAXY_ENV'?
I haven't fully thought this out so there may be reasons why this won't
work in cluster environments, but it should be something we can add to
the job template.
--nate
Best,
Florent
On 16/02/11 05:58, Nate Coraor wrote:
>Hi Florent, et. al.,
>
>I've moved the discussion over to galaxy-dev since it pertains to local
>instances.
>
>Florent Angly wrote:
>>Indeed, this workaround works! Thank you.
>>I added these lines to the beginning of my run.sh:
>> PATH="/opt/local/bin:/opt/local/sbin:$PATH"
>> export $PATH
>>
>>Now, Galaxy can find Grinder, Velvet, etc....
>>
>>Could Galaxy detect and use ~/.profile automatically if it exists?
>>Alternatively, maybe there should be a place in the configuration
>>file universe_wsgi.ini to specify which file to read environment
>>variables from? Is it worth filing an enhancement request in the bug
>>tracker?
>Unfortunately, this is really more of an issue with the way shells are
>designed. Galaxy can't make too many assumptions about how you want the
>environment to be set up, especially since it's run under a variety of
>shells. What's going to happen is dependent entirely upon how the
>parent shell to Galaxy is started.
>
>By default if invoked in non-login, non-interactive mode (which would
>likely be the case for most managed startup methods like launchd, rc
>scripts, etc.), bash will not read *any* startup files. This behavior
>can be changed by specifying the path to a file to be sourced in the
>$BASH_ENV environment variable in the calling environment.
>
>However, when bash is called as 'sh', even $BASH_ENV is not available.
>
>For more details, see the "INVOCATION" section of the bash(1) man page.
>
>Since the public site runs on Solaris, we solve this by setting $PATH
>and any other relevant variables within SMF. Similar methods should
>work (setting the $PATH in an init script or in the LaunchDaemon plist)
>for other startup methods.
>
>Although modifying run.sh as mentioned does work, modifications could
>conflict with future changes from the upstream source repository.
>
>--nate
>
>P.S. I'll add a plug for zsh - its invocation is much less confusing
> and ~/.zshenv is *always* read regardless of invocation.
>
>>Again, thanks for the help.
>>
>>Florent