[galaxy-dev] Mapping requirements to conda recipe names (granularity?)

[Peter van Heusden]

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/

Re: [galaxy-dev] Auto detection of output format Galaxy custom tool

[Peter van Heusden]

Hi Katherine

I presume this is related to the tool described here (
https://biostar.usegalaxy.org/p/18319/)? I think there is general interest
in the creation of a tool like this - see the recent email from Miu ki Yip.
If you could share the code and XML (e.g. via GitHub) perhaps we could
assist with what you are trying to write.

Peter

On 30 June 2016 at 19:01, Peter Cock  wrote:

> Maybe sharing your tool XML file would be best - is it on GitHub?
>
> Peter
>
> On Wed, Jun 29, 2016 at 7:43 PM, Katherine Beaulieu
>  wrote:
> > Ok, so I don't give the user the option to select the correct data type
> to
> > reduce the amount of stuff the user has to know when using the tool.
> >
> > I do leave the format as auto and Galaxy just leaves it as the generic
> data
> > type 'data'.
> >
> > As for how the format is defined in Galaxy, I'm not quite sure what the
> > answer to this question is because I am just testing the tool with really
> > simple text files, with extension .txt. and it can't seem to pick it up,
> it
> > just leaves it as 'data'. Also not quite sure how to test the Python
> code in
> > the sniff function outside of Galaxy... (only starting working with
> Galaxy 3
> > weeks ago).
> >
> > Let me know if I should provide you with the tool config file if that
> would
> > be a little more useful. It's quite straightforward
> > Thanks for helping with this.
> >
> ___
> 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/
>
___
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/