- class flytekit.core.base_task.TaskResolverMixin#
Flytekit tasks interact with the Flyte platform very, very broadly in two steps. They need to be uploaded to Admin, and then they are run by the user upon request (either as a single task execution or as part of a workflow). In any case, at execution time, for most tasks (that is those that generate a container target) the container image containing the task needs to be spun up again at which point the container needs to know which task it’s supposed to run and how to rehydrate the task object.
For example, the serialization of a simple task
# in repo_root/workflows/example.py @task def t1(...) -> ...: ...
might result in a container with arguments like
pyflyte-execute --inputs s3://path/inputs.pb --output-prefix s3://outputs/location --raw-output-data-prefix /tmp/data --resolver flytekit.core.python_auto_container.default_task_resolver -- task-module repo_root.workflows.example task-name t1
At serialization time, the container created for the task will start out automatically with the
pyflyte-executebit, along with the requisite input/output args and the offloaded data prefix. Appended to that will be two things,
locationof the task’s task resolver, followed by two dashes, followed by
the arguments provided by calling the
default_task_resolverdeclared below knows that
loader_argsis called on a task, to look up the module the task is in, and the name of the task (the key of the task in the module, either the function name, or the variable it was assigned to).
load_taskis called, it interprets the first part of the command as the module to call
importlib.import_moduleon, and then looks for a key
This is just the default behavior. Users should feel free to implement their own resolvers.
Future proof method.
Given the set of identifier keys, should return one Python Task or raise an error if not found
Return a list of strings that can help identify the parameter Task
Overridable function that can optionally return a custom name for a given task