Turns out integers are used as is in `random.seed()`, but strings are
hashed (in the version 1 protocol), and the hashing isn't stable. So
instead we hack around this by using `ord()` on each character and
concatenating the digits. Yucky, but probably better than using numpy
and putting this tool on the list of tools that inherit galaxy's
environment (or adding a requirement tag and resolving with conda ...).
This seems to be necessary so that the workflow_stability test passes
under python 2 and python3, but does change the result under python 2,
hence the updated workflows (produced by uploading and downloading the
workflow to an instance running with this commit).
Allow the rules DSL & GUI component to operate on existing collections to allow filtering, sorting, modifying identifiers and general re-organization of existing collections (e.g. the outputs of tools). Implementing this as a collection operation tool so that it should be executable interactively in the tool form and in a batch fashion as part of workflow executions.
For this to be tracked properly as a tool execution and to work properly in the tool form, I've implemented a new tool framework and tool form parameter type called "rules".
This can thought of as a more GUI friendly alternative to my proposed collection operations that consumed JavaScript expressions.
This includes API tests for both tool and workflow execution of the new tool as well as Selenium tests for tool form execution, workflow editor interactions, and workflow running.
This is using the simplest of workflows. I had to
remove the chromInfo part from the workflow, because the
path referenced would be changed dynamically and so the
job search wouldn't recognize this as being equivalent.
- Move api.helpers to base.populators.
- Refactor helper subclasses adapted to use bioblend instead of test framework stuff into base.populators for greater visibility.
- Refactor workflow format 2 testing stuff for reuse by Selenium.
Marius van den Beek