The fimo tool was removed from `tool_conf.xml.sample` in 2014
(commit fa11d10c8b) and migrated to the
tools-iuc repository since 2015
( https://github.com/galaxyproject/tools-iuc/pull/499 ).
This bundled version doesn't probably work any more and is not
available on the UseGalaxy.* servers.
This allows us to remove `galaxy-sequence-utils` from the project
dependencies, since the other 2 tools
(`lib/galaxy/datatypes/converters/vcf_to_interval_index_converter.xml`
and `tools/maf/vcf_to_maf_customtrack.xml`) correctly specify it as a
requirement.
If you want to run or collect workflow tests now you've got to indicate
the full path currently (i.e. `pytest --collect-only
lib/galaxy_test/workflow/tests.py`). With this change `pytest
--collect-only lib/galaxy_test/workflow/` or just `pytest --collect-only
lib/galaxy_test/` will also discover the workflow tests.
These are available in a list(n) x list (m) -> list(nxm) version (a cross product that produces two flat lists) and a list(n) x list(m) -> list(n):list(m) version (a cross product that produces two nested lists).
After two lists have been run through one of these two tools - the result is two new lists that can be passed into another tool to perform all-against-all operations using Galaxy's normal collection mapping semantics.
The choice of which to use will depend on how you want to continue to process the all-against-all results after the next step in an analysis. My sense is the flat version is "easier" to think about and pick through manually and the nested version perserves more structure if additional collection operation tools will be used to filter or aggregate the results.
Some considerations:
Apply Rules?
I do not believe the Apply Rules tool semanatics would allow these operations but certainly the Apply Rules tool could be used to convert the result of the flat version to the nested version or vice versa - so no metadata is really lost per se between the two versions. I think it is still worth including both versions though - they both have utility (both for instance are baked into CWL's workflow semantics - https://docs.sevenbridges.com/docs/about-parallelizing-tool-executions#nested-cross-product) and avoiding requiring complex Apply Rules programs for simple workflows is probably ideal.
One Tool vs Two?
Marius and I agree that few simpler tools for these kinds of operations are better. The tool help can be more focused and avoiding the conditional and conditional outputs make the static analysis done for instance by the workflow editor simpler.
Otherwise alembic/env.py gets executed out of context at test collection
stage (via tox -e unit >> run_tests.sh), which raises an AttributeError
(alembic.context is not set in this case).
Same solution as in 3be1f6fef3
Also minor reformat.
Pip 20.3 added support for PEP 600, i.e. manylinux wheels using platform
tags of the form "manylinux_${GLIBCMAJOR}_${GLIBCMINOR}_${ARCH}". Fix
installation of dependencies like pysam 0.20.0 wheels, which otherwise need
to be built from source and can fail as reported by @assuntad23 in
https://gist.github.com/assuntad23/3022db63a6878f044a209961dd40e592
Also:
- Install `wheel` to fix warning like `Using legacy setup.py install for
beaker, since package 'wheel' is not installed.`
- Drop unnecessary `defaults` channel from conda commands.
- Fix "SC2223: This default assignment may cause DoS due to globbing. Quote
it." errors reported by `shellcheck -x` .
Otherwise alembic/env.py gets executed out of context at test collection
stage (via tox -e unit >> run_tests.sh), which raises an AttributeError
(alembic.context is not set in this case)
1) Download conformance tests to `test/functional/tools/cwl_tools` where
they can be used also by framework and unit tests in the future.
2) Add populators to enable executing CWL conformance tests
3) Generate CWL conformance API tests only when needed for tests
- Allow specifying Python to use to create virtualenv using GALAXY_PYTHON
environment variable.
- Integrate Python support docs from https://galaxyproject.org/admin/python/
- Update virtualenv installation to use v16.7.9
The actual database to target is generated dynamically, but since
GALAXY_CONFIG_OVERRIDE_DATABASE_CONNECTION takes precedence the
wrong database is used.
Nicola Soranzo