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
> 
_______________________________________________
To manage your subscriptions to this and other Galaxy lists, please use the 
interface at:

  http://lists.bx.psu.edu/

Reply via email to