There is a point in the docs about providing input...
# ask-community
There is a point in the docs about providing inputs to an op that made me stop:
An op only starts to execute once all of its inputs have been resolved. Inputs can be resolved in two ways:
• The upstream output that the input depends on has been successfully emitted and stored.
The input was stubbed through config. How does one “stub” an input “through config”? Is it somehow possible to have a simple op
Copy code
def my_op(my_input:str):
    # do something with my_input
    # ...
and provide
through a Pythonic config object without having to do something like this:
Copy code
@op(ins={"my_input": In(Optional[str], default_value=None)})
def my_op(config: MyConfig, my_input:str | None = None):
    my_input = my_input if my_input is not None else config.configured_input
I wouldn’t consider the latter as “stubbing” the input, given that all the gymnastics around finding the actual value is done in the body of the function. Am I missing something here?
🤖 1
If you want a simple add a parameter to an op, you can do that. If you’re going to do a MyConfig, I don’t see why you wouldn’t add
to that. Here’s an example op with an array of Outputs passed to it
Copy code
@op(ins={"start": In(Nothing)})
def OrderPipeline(context, nums: List[Output]):
    shell_script_runner(context, "MyOrderPipeline.ksh")
Hi Andras, The “stubbing” being referred to here is using the “inputs” field for an op on the run config schema:
Copy code
from dagster import job, op

def foo(a: int) -> int:
    return a + 1

def foo_job():

    run_config={"ops": {"foo": {"inputs": {"a": 1}}}}
I realize the terminology is confusing, but this is separate from the “config” for the op, (i.e. what the op’s config schema defines).
Hi @sean, totally makes sense, thanks! Can I contribute to the docs to clarify this?
Thanks for the offer, but it’s such a small change that it’s not worth the overhead of a community PR, so I created a PR that links to the right place: