Global variables as context

[philtweir]

From discussion

The current approach to define workflow inputs is to use global variables
as shown in the Parameters help section - one may intuitively expect to define workflow input by
defining global variables and passing 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)

The produced output reads

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

Currently the only intended way of defining workflow input is using global
variables.

Proposal

• can we remove 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]

can we remove 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

I disagree that only pure functions are functions, and a concept based solely on pure functions does not map to the paradigm of a workflow, which is the goal of dewret. Nearly all workflow description languages use global level inputs, which correspond directly to global variables -- while they are mapped as explicit inputs to an individual step, any step, no matter how deeply nested, can access the global level inputs.

Moreover, given that these context-aware functions can be directly mapped to pure functions taking explicit input (by un-/currying), these two concepts are theoretically identical, and the difference is in notation - but the current approach is still closer to the intention and notation of standard workflow description systems.

Perhaps a more palatable way of viewing this is that the python module represents the workflow, and the global scope of the module is equivalent to the global scope of the workflow. We could treat it a bit like pytest fixtures, where an argument in the signature that is not explicitly added in a call is pulled in from the "global" variables - that makes the task's dependencies visually explicit, and better matches the semantics of most workflow definition languages, but abuses Python's coding paradigm and breaks type hinting, by introducing inconsistency between a call and a signature.

[philtweir]

As a side-note to this - I think the fundamental difference between a problematic "global state" (which I think is the objection) and an implementation of global input (which we have) that's trivially isomorphic to a (theoretical) implementation with pure functions is the possibility of side-effects. We do not support changing any global input -- however, I do think a very sensible action point from this discussion would be explore how we can enforce this, so an error is raised if a task attempts to change a global variable.