Mapping requirements to conda recipe names (granularity?)
Hi there I'm trying to satisfy requirements on our RNA-seq oriented Galaxy server at SANBI using conda/bioconda. There's a disconnect between the names used in tool dependency tags and the names of conda recipes though, for example: 1) the BAM to BigWig converter (tool ID CONVERTER_bam_to_bigwig_0) has a requirement for ucsc_tools. The tool it needs, bedGraphToBigWig, is provided by the ucsc-bedgraphtobigwig package, so in this case ucsc_tools is a broader requirement than what bioconda provides. 2) the featurecounts tool requires featurecounts, which is part of the subreads recipe, so in this case featurecounts is a narrow requirement than what is provided in bioconda. In the second case, one could say subreads provides the featurecounts requirement. In the first case one could say the tool requires a narrower requirement than what it specifies, although the bioconda recipes split a single upstream package (ucsc_tools) into multiple recipes that invariable will be updated together, a somewhat strange choice. Right now I'm resolving these problems by manually creating environments (e.g. __package__featurecounts@__unversioned__) that will get picked up by the conda dependency resolver, but I'd like to hear from the list what the best way to support this is? Probably the easiest is keeping the tool requirements definition in line with what the conda recipe is called, but in some cases a mapping table between requirements and conda recipe names could be useful. Peter
I believe shipping a mapping file with Galaxy (& galaxy-lib) is a good way to go - there is an existing github issue on this: https://github.com/galaxyproject/galaxy/issues/1927 Hopefully this could be made generic enough to be useful with other resolvers such as environment modules and future resolvers such as Debian packages. -John On Sun, Jul 3, 2016 at 4:52 PM, Peter van Heusden <pvh@sanbi.ac.za> wrote:
Hi there
I'm trying to satisfy requirements on our RNA-seq oriented Galaxy server at SANBI using conda/bioconda. There's a disconnect between the names used in tool dependency tags and the names of conda recipes though, for example:
1) the BAM to BigWig converter (tool ID CONVERTER_bam_to_bigwig_0) has a requirement for ucsc_tools. The tool it needs, bedGraphToBigWig, is provided by the ucsc-bedgraphtobigwig package, so in this case ucsc_tools is a broader requirement than what bioconda provides.
2) the featurecounts tool requires featurecounts, which is part of the subreads recipe, so in this case featurecounts is a narrow requirement than what is provided in bioconda.
In the second case, one could say subreads provides the featurecounts requirement. In the first case one could say the tool requires a narrower requirement than what it specifies, although the bioconda recipes split a single upstream package (ucsc_tools) into multiple recipes that invariable will be updated together, a somewhat strange choice.
Right now I'm resolving these problems by manually creating environments (e.g. __package__featurecounts@__unversioned__) that will get picked up by the conda dependency resolver, but I'd like to hear from the list what the best way to support this is? Probably the easiest is keeping the tool requirements definition in line with what the conda recipe is called, but in some cases a mapping table between requirements and conda recipe names could be useful.
Peter
___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: https://lists.galaxyproject.org/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
participants (2)
-
John Chilton -
Peter van Heusden