An ``<environment_variables>`` top-level XML block can be used to define these.
```
<environment_variables>
<environment_variable name="FOO">$bar</environment_variable>
<environment_variable name="FOO2">$bar2</environment_variable
</environment_variables>
```
The expressions are contained in the text of the block.
Implementation Detials:
In order to avoid odd shell expression stuff - the evaluated expressions are written to files and environment variables are read from these files at runtime.
Testing:
A demo tool ``test/functional/tools/environment_variables.xml`` with a test case that can be executed with the following expression.
```
./run_tests.sh -framework -id environment_variables
```
Previously there were two hard-coded toke types at_tokens an dollar_tokens. Now all tokens for the same macro must have the same wrap string and this string can be set arbitrarily with token_quote attribute. The defualt token_quote value is @.
This comes in two modes - simple lists of required attributes and per-attribute parameters that may specify defaults.
The following toy example:
```
<tool>
<expand macro="inputs" bar="hello" />
<macros>
<xml name="inputs" dollar_tokens="bar">
<inputs type="the type is $BAR$" />
</xml>
</macros>
</tool>
```
will evalute to ``<tool><inputs type="the type is hello" /><tool>``. The XML macro definition tag can now take in two new fixed attributes dollar_tokens and at_tokens - which will be interpreted as a list of parameter names. Each parameter can be specified when expanding the macros as simple attributes specifying the value of the parameter. The "dollar" parameter with name bar would map to a token with name $BAR$. Likewise an "at" parameter with name foo would map to a token with name @FOO@.
Both parameter types can be specified on a per-parameter basis to also specify default values. So the following example:
```
<tool>
<expand macro="inputs" foo="hello" />
<expand macro="inputs" foo="world" />
<expand macro="inputs" />
<macros>
<xml name="inputs" at_token_foo="the_default">
<inputs>@FOO@</inputs>
</xml>
</macros>
</tool>
```
Would evalute to ``<tool><inputs>hello</inputs><inputs>world</inputs><inputs>the_default</inputs>``.
Updated unit tests explain the above much more succinctly - though some like English and words for reasons that escape me.
Runtime post job actions are post job actions inserted when the workflow is invoked instead of being part of the workflow object in the database. The bug noticed by @kellrott was that these actions were being appended to the original workflow post job actions instead of being transient things just attached to the jobs themselves.
This fixes that problem and adds a test to try to prevent regressions.
- Allow boolean "truevalue"/"falsevalue" to be used in plain (non-conditional test element) parameters (see https://trello.com/c/iGk3f1pE).
- Fix conditionals to use processed values - so this fix and 5b6c092aa0 are applid to these elements as well. (http://osdir.com/ml/general/2015-05/msg24402.html).
This also adds tests to verify these behaviors.
Run most relevant tests with commands:
./run_tests.sh -framework -id simple_constructs
./run_tests.sh -framework -id multi_select
./run_tests.sh -framework -id boolean_conditional
When finding methods to invoke it seems nose uses the raw function name instead of the class's attribute name (I guess this terminology makes sense), but when reporting results it uses the latter. Synchronizing these names therefore allows calling specific tool test methods from the command-line.
This change is required to implement galaxyproject/planemo#145.
Dannon Baker