Okay.
So 'binary' and 'python-module' module are currently just treated
differently from 'package' in this context because they are kind of
not in use? But isn't it then a good idea to also include these type
tags into the dependency management system by generally changing this
line to:
On Tue, Sep 10, 2013 at 9:16 AM, Hans-philipp Brachvogel
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 xyz
>
> They do not handle type="pytho
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 type="package">xyz
They do not handle type="python-module", which is what I am looking for (beacuse of our
Phil,
Galaxy uses a number of ways to resolve tool dependencies, some of which
may be useful in your situation:
1. If a tool dependency entry exists in the database that matches the
name, type, and version, it attempts to load
tool_dependency_dir/package_name/version/repository_owner/reposit
Hi all,
we run galaxy on a cluster and real user job sumission (via DRMAA).
The problem is getting the Galaxy standard tools to work with
environment-module.
We use environment-modules to fit the environment to the needs of a
job and want to do the same for galaxy jobs. I highly expect th
