(self, path):

"""Checks if a path exists."""

...As each component defines a different interface, make sure to check out the base class definition of the component type that you want to implement and also check out the documentation on how to extend specific stack components.

If you would like to automatically track some metadata about your custom stack component with each pipeline run, you can do so by defining some additional methods in your stack component implementation class as shown in the Tracking Custom Stack Component Metadata section.

See the full code of the base StackComponent class here.

Base Abstraction 2: StackComponentConfig

As the name suggests, the StackComponentConfig is used to configure a stack component instance. It is separated from the actual implementation on purpose. This way, ZenML can use this class to validate the configuration of a stack component during its registration/update, without having to import heavy (or even non-installed) dependencies.

The config and settings of a stack component are two separate, yet related entities. The config is the static part of your flavor's configuration, defined when you register your flavor. The settings are the dynamic part of your flavor's configuration that can be overridden at runtime.

You can read more about the differences here.

Let us now continue with the base artifact store example from above and take a look at the BaseArtifactStoreConfig:

from zenml.stack import StackComponentConfig

class BaseArtifactStoreConfig(StackComponentConfig):

"""Config class for `BaseArtifactStore`."""

path: str

SUPPORTED_SCHEMES: ClassVar[Set[str]]

...

Through the BaseArtifactStoreConfig, each artifact store will require users to define a path variable. Additionally, the base config requires all artifact store flavors to define a SUPPORTED_SCHEMES class variable that ZenML will use to check if the user-provided path is actually supported by the flavor.

See the full code of the base StackComponentConfig class here.

Base Abstraction 3: Flavor