Hi! This example illustrate how to execute another...
# ask-community
j
Hi! This example illustrate how to execute another job within an op. In this case I pass the
job_name
as a parameter. I am trying to get the JobDefinitions from my repo using the
job name
, all nice when working in a single file (see example below). But I want to be able to organize my code better the problem is that I need
my_repo.get_job()
function to get the actual JobDefinition. If I move my job or op within another folder I get this circular dependency error basically because I am using
my_repo
reference. Is there a better way to do this? or another way to get the instance of my repository? Would be nice if the op context got a reference to my repository
Copy code
from dagster import (
    job,
    repository,
    OpExecutionContext,
    Field,
    op,
)


# *****************************************************
# *****************************************************
# NOTE: This job and op need to here, for a technical problem about circular importing.
# In the future we need to find a way to move this code to their own folders
@op(
    config_schema={
        "job_name": Field(str),
    }
)
def my_op(context: OpExecutionContext):
    job_name = context.op_config["job_name"]
    job = my_repo.get_job(job_name)

    job.execute_in_process(
        instance=context.instance,
    )


@job(
    config={
        "ops": {
            "my_op": {
                "config": {
                    "job_name": "my_assets_job",
                }
            }
        }
    }
)
def my_job():
    my_op()


# *****************************************************
# *****************************************************


@repository
def my_repo():
    return [my_job, myOtherDefinitions...]
Should the repositoryDefinition be available in the opcontext?
c
core apis are starting to move away from repositories in favor if definitions; I don’t think we currently expose repository definition on the
OpExecutionContext
and I don’t think we will… however, perhaps you could achieve what you want by nesting the import within the actual op definition itself. That should avoid circular imports
j
That actually worked (import nested in function)
Thank you
c
blob salute