On Tue, Sep 10, 2013 at 9:16 AM, Hans-philipp Brachvogel <hans-philipp.brachvogel@student.uni-tuebingen.de> wrote:
Hey Dave,
thanks for the reply! Guess I wrote too much and explained badly what I meant. I had already tested the Managed Tool Dependencies, but my problem was that those only work for <requirement type="package">xyz</requirement>
They do not handle <requirement type="binary"... or <requirement type="python-module", which is what I am looking for (beacuse of our special setting). Anyhow, I searched a bit and found in galaxy_dir/lib/galaxy/tools/__init__.py. at line 2671:
if requirement.type in [ 'package', 'set_environment' ]: script_file, base_path, version = self.app.toolbox.dependency_manager.find_dep...
So I changed that line to:
if requirement.type in [ 'package', 'set_environment', 'binary', 'python-module' ]
This works, for me. If I have e.g.: <requirement type="python-module">rpy</requirement> I can now use dep_dir/rpy/default/env.sh to also load R into the environment.
Now, I wonder if that change will have any bad consequences? I could not find anything about the requirement type 'binary' and 'python-module', what are they normally needed for? Could this be relevant when using tool-shed?
Phil
These dependency declarations pre-date the Tool Shed and are (as far as I know) ignored by the Tool Shed. They may currently be non-functional, but I think they could be useful with a little magic added to the Galaxy jobs to check the dependency as part of the shell script submitted for the job (to give nice clear failure errors about missing dependencies, rather than what ever cryptic error the tool may give). Peter