Align on treatment of global variables (feedback 1-20)

[philtweir]

[id: 1-20], [CONCEPT], [FUND] The current approach to define workflow inputs is to use global variables
as shown in the Parameters help section, right? Personally, I was a bit surprised by this approach. Before
that I had played around with dewret and the way I intuitively expected to define workflow input was to
define global variables and pass them as arguments to tasks, e.g.

import sys
import yaml
from dewret.tasks import task, run
from dewret.renderers.cwl import render
some_number = 3
@task()
def increment(num: int) -> int:
  return num + 1
result = increment(num=some_number)
workflow = run(result)
cwl = render(workflow)
yaml.dump(cwl, sys.stdout, indent=2)

Which obviously does not work, i.e. the produced output reads

class: Workflow
cwlVersion: 1.2
inputs: {}
outputs:
out:
label: outoutputSource: increment-012ef3b3ffb9d15c3f2837aa4bb20a8d/out
type: int
steps:
increment-012ef3b3ffb9d15c3f2837aa4bb20a8d:
in:
num:
default: 3
out:
- out
run: increment

Hence, it seems that currently the only intended way of defining workflow input is using global
variables which sneak into a function (as context). I know this is very subjective (so, please no offence!)
but I strongly reject the concept of context aware functions because they are violating the
encapsulation and the very idea behind a function, i.e. that a function should be a stateless and entirely
encapsulated entity whose result should only depend on the explicit input.

[philtweir]

Start discussion #20

[elleryames]

The desired behavior in the example above is now implemented with #27