Skip to content

[Suggestion] Compromise between flowrep and PWD #19

@samwaseda

Description

@samwaseda

I guess I found an acceptable compromise between @JNmpi and @liamhuber to fill the gap between flowrep and @jan-janssen's PWD.

I would suggest to delete inputs and outputs from flowrep, and remove invisible function arguments, in order not to have to inspect the actual functions. Let's take the following workflow as an example:

def operation(x: float, y: float) -> tuple[float, float]:
    return x + y, x - y


def add(x: float = 2.0, y: float = 1) -> float:
    return x + y


def multiply(x: float, y: float = 5) -> float:
    return x * y


def example_workflow(a=10, b=20):
    c, d = operation(a, b)
    e = add(c, y=d)
    f = multiply(e)
    return f
{
    "nodes": {
        "operation_0": {
            "function": {
                "module": operation.__module__,
                "qualname": operation.__qualname__,
                "version": "not_defined",
            },
            "type": "Function",
        },
        "add_0": {
            "function": {
                "module": add.__module__,
                "qualname": add.__qualname__,
                "version": "not_defined",
            },
            "type": "Function",
        },
        "multiply_0": {
            "function": {
                "module": multiply.__module__,
                "qualname": multiply.__qualname__,
                "version": "not_defined",
            },
            "type": "Function",
        },
    },
    "edges": [
        ("inputs.a", "operation_0.inputs.0"),
        ("inputs.b", "operation_0.inputs.1"),
        ("operation_0.outputs.output[0]", "add_0.inputs.0"),
        ("operation_0.outputs.output[1]", "add_0.inputs.y"),
        ("add_0.outputs.output", "multiply_0.inputs.0"),
        ("multiply_0.outputs.output", "outputs.f"),
    ],
    "label": "example_macro",
    "type": "Workflow",
}

I put module, qualname etc., but I guess I would even want to have the actual python functions instead. Anyway, this dictionary can be passed to other tools such as semantikon to retrieve the full IO information. This representation has the following advantages

  • It does not contain IO (as @JNmpi wished)
  • No inspection required to create this representation (as @liamhuber wished)
  • 0, 1 etc. for the input arguments are actually even required for some functions, such as range
  • This creates a clear separation between semantikon and flowrep, as flowrep does not need to know anything about the underlying functions

Let me know what you think

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions