Previously this would reference the parent workflow index, while the
get_data module would use the subworkflow index. This means defining
workflows worked fine, but executing would fail when trying to find the
output to replace. Using the subworkflow index here seems like the
correct thing to do.
Fixes https://github.com/galaxyproject/galaxy/issues/6560
Since v2.27.0 (see
https://github.com/arq5x/bedtools2/commit/4d188435777cfbd6ada7394ee78fde37f07c9a75 ),
`bedtools genomecov` emits this warning:
```
*****
*****WARNING: Genome (-g) files are ignored when BAM input is provided.
*****
```
if both `-ibam` and `-g` option are specified, which causes the converters to
always fail.
Also:
- Add `detect_errors="aggressive"` to `<command/>` to prevent future warnings from
creating other issues.
- Fix input format in `CONVERTER_sam_to_bigwig_0`.
This doesn't quite work because of the dynamic output collection,
which fails with:
```
galaxy.tools.parameters.output_collect DEBUG 2018-06-06 18:40:38,784 (3) Add dynamic collection datasets to history for output [reverse] (171.970 ms)
galaxy.tools.parameters.output_collect ERROR 2018-06-06 18:40:38,839 Problem gathering output collection.
Traceback (most recent call last):
File "/Users/mvandenb/src/galaxy/lib/galaxy/tools/parameters/output_collect.py", line 340, in collect_dynamic_outputs
collection_builder.populate()
File "/Users/mvandenb/src/galaxy/lib/galaxy/dataset_collections/builder.py", line 88, in populate
elements = self.build_elements()
File "/Users/mvandenb/src/galaxy/lib/galaxy/dataset_collections/builder.py", line 59, in build_elements
new_elements[identifier] = element.build()
AttributeError: 'HistoryDatasetAssociation' object has no attribute 'build'
```
This seems to happen because the inner collection is wrongly detected as
nested. In general I doubt that mapping over colleciton output works
with dynamically discovered output collections.
Previously this would have always generated `list:list` structures,
even when the input is a list:pair. I'm not 100% convinced
this is correct, but this seems to work.
We'd only try mapping over the first collection type description
otherwise. I suppose we didn't notice because the first type is `list`
and therefore much more common. Noticed this while working on https://github.com/galaxyproject/galaxy/pull/5640.
Dannon Baker