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.
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
Florent Angly wrote: 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