Running

Flyte SDK lets you seamlessly switch between running your workflows locally on your machine and running them remotely on your Union/Flyte instance.

Furthermore, you perform these actions either programmatically from within Python code or from the command line using the flyte CLI.

Running remotely

From the command-line

To run your code on your Union/Flyte instance, you can use the flyte run command without the --local flag:

flyte run hello.py main

This deploys your code to the configured Union/Flyte instance and runs it immediately (Since no explicit --config is specified, the configuration found according to the default configuration search will be used).

From Python

To run your workflow remotely from Python, use flyte.run() by itself, like this:

# hello.py

... # Your sub-task definitions here

@env.task
def main(name: str):
     ... # The main task logic here

if __name__ == "__main__":
    flyte.init_from_config()
    flyte.run(main, name="Ada")

This is the approach we use throughout our examples in this guide. We execute the script, thus invoking the flyte.run() function, with the top-level task as a parameter. The flyte.run() function then deploys and runs the code in that file itself on your remote Union/Flyte instance.

Running locally

From the command-line

To run your code on your local machine, you can use the flyte run command with the --local flag:

flyte run --local hello.py main

From Python

To run your workflow locally from Python, you chain flyte.with_runcontext() with flyte.run() and specify the run mode="local", like this:

# hello.py

... # Your other task definitions here

@env.task
def main(name: str):
     ... # The main task logic here

if __name__ == "__main__":
    flyte.init_from_config()
    flyte.with_runcontext(mode="local").run(main)

Running your workflow locally is useful for testing and debugging, as it allows you to run your code without deploying it to a remote instance. It also lets you quickly iterate on your code without the overhead of deployment.

Obviously, if your code relies on remote resources or services, you will need to mock those in your local environment, or temporarily work around any missing functionality. At the very least, local execution can be used to catch immediate syntax errors and other relatively simple issues before deploying your code to a remote instance.