sourceSettings(...)})

def my_step() -> None:

...Deprecating the requirements and required_integrations parameters

Users used to be able to pass requirements and required_integrations directly in the @pipeline decorator, but now need to pass them through settings:

How to migrate: Simply remove the parameters and use the DockerSettings instead

from zenml.config import DockerSettings

@step(settings={"docker": DockerSettings(requirements=[...], requirements_integrations=[...])})

def my_step() -> None:

...

Read more here.

A new pipeline intermediate representation

All the aforementioned configurations as well as additional information required to run a ZenML pipelines are now combined into an intermediate representation called PipelineDeployment. Instead of the user-facing BaseStep and BasePipeline classes, all the ZenML orchestrators and step operators now use this intermediate representation to run pipelines and steps.

How to migrate: If you have written a custom orchestrator or step operator, then you should see the new base abstractions (seen in the links). You can adjust your stack component implementations accordingly.

PipelineSpec now uniquely defines pipelines

Once a pipeline has been executed, it is represented by a PipelineSpec that uniquely identifies it. Therefore, users are no longer able to edit a pipeline once it has been run once. There are now three options to get around this:

Pipeline runs can be created without being associated with a pipeline explicitly: We call these unlisted runs. Read more about unlisted runs here.

Pipelines can be deleted and created again.

Pipelines can be given unique names each time they are run to uniquely identify them.

How to migrate: No code changes, but rather keep in mind the behavior (e.g. in a notebook setting) when quickly iterating over pipelines as experiments.

New post-execution workflow

The Post-execution workflow has changed as follows: