Galaxy: Ship a package-to-conda mapping file with Galaxy

Created on 15 Mar 2016 · 6Comments · Source: galaxyproject/galaxy

When abstract packages don't map directly to conda packages (e.g. https://github.com/galaxyproject/tools-iuc/pull/642/files) a file inside of Galaxy should provide a concrete mapping.

For local testing, planemo should read some file or something in .shed.yml to override this for local testing (conda_dependencies.xml :wink:) - but Galaxy will have no concept of this file.

aretool-framework aretools

Source

jmchilton

Most helpful comment

In https://github.com/galaxyproject/tools-iuc/pull/710/files/26e320ba917e0d8e3fb472fe5777ec3f5dcc7bdd#r58512818 I proposed an alternative solution: a new optional resolver attribute for <requirement type="package"> whose value would be a comma-separated list of strings among tool_shed_packages, conda and the other resolvers specified in config/dependency_resolvers_conf.xml.sample .

When found, this attribute will instruct Galaxy to resolve this requirement only with one of the specified resolvers (in the order specified in config/dependency_resolvers_conf.xml). If the attribute is not specified, Galaxy will handle the requirement as it is doing now.

I think this would be a cleaner and more transparent solution than the package-to-conda mapping file.

nsoranzo on 11 Jul 2016

👍3

All 6 comments

I think this would be a cleaner and more transparent solution than the package-to-conda mapping file.

nsoranzo on 11 Jul 2016

👍3

I can see the merits of both solutions. I like having a mapping file that is controlled by the Galaxy admin, as an admin I like to have control over how things are installed. However, as a tool author, it would be very nice to have some mechanism to specify attributes for specific resolvers when necessary. There will inevitably be cases where homebrew package names differ from conda package names. A simple and sane default is great, and having the flexibility to specify exceptions is also very useful.

lparsons on 11 Aug 2016

+1 on explicit resolvers for cases where different packaging sources have adopted different names for the same package (e.g. for NCBI BLAST vs BLAST+).