Hi,
has anything changed in galaxy in this regard?
Any way to modify an environment before a tools is run?
I now have a tool relying on R-devel and bioconductor devel, both of which I
can load in a module.
The tool comes from the toolshed with xml like:
command interpreter=Rscript
…
I don't
Hi Ido,
I do not get your question in all detail, but it is possible to define a
tool_dependencies.xml with a specific R version, + R libraries and use
only that specific version from your tool with requirement tags.
For an example please see various R tools from:
Dear Björn,
maybe I could change the tool, which is not mine, and which I don't want to
maintain to use a specific R-version that is already available on our cluster
and
which I can put into my path with module load R/3.1.0-devel (
http://modules.sourceforge.net/)
there even is a
Hello Ido,
Reading through your e-mail it is not clear to me whether the tool has
requirements that could be overridden. If it has package requirements
explicitly defined - those are completely configurable - you can write
arbitrary python plugins to resolve these any you wish - and (if the
On Apr 25, 2014, at 3:55 PM, John Chilton jmchil...@gmail.com wrote:
Additionally (perhaps more pertinently), I have an open pull request
(created just this week) to allow setting environment variables on a
per destination basis - this is sort of what you are getting at and
might be a better
Just been reading a bit more about the Galaxy packaging system. Here's a
slight modification to what I was suggesting that might fit in a bit better.
Apologies for not being more familiar with the existing system before proposing
extensions.
Recall that my goal is to support using a
I'd like to propose a slightly different approach.
I don't like the idea of introducing a different type of requirement
for this because it really isn't a different type of requirement. You
are still requiring a package, you just want to use a different
mechanism to provide it.
So, instead, what
Setting the environment for each tool just prior to running the tool is
clearly better.
What I'm doing currently is loading an environment module just before running
a tool in Galaxy.
On our HPC cluster, I have configured Galaxy to source the following
from our modules system:
1) Global
