latch_cli.services.register package#

Submodules#

latch_cli.services.register.constants module#

latch_cli.services.register.register module#

latch_cli.services.register.register.print_and_write_build_logs(build_logs: Iterable[DockerBuildLogItem], image: str, pkg_root: Path, *, progress_plain: bool = False)[source]#
latch_cli.services.register.register.print_upload_logs(upload_image_logs, image)[source]#
latch_cli.services.register.register.print_serialize_logs(serialize_logs, image)[source]#
latch_cli.services.register.register.register(pkg_root: str, *, disable_auto_version: bool = False, remote: bool = False, open: bool = False, skip_confirmation: bool = False, snakefile: Path | None = None, progress_plain: bool = False, cache_tasks: bool = False, use_new_centromere: bool = False)[source]#

Registers a workflow, defined as python code, with Latch.

Kicks off a three-legged OAuth2.0 flow outlined in RFC6749. Logic scaffolding this flow and detailed documentation can be found in the latch.auth package

From a high-level, the user will be redirected to a browser and prompted to login. The SDK meanwhile spins up a callback server on a separate thread that will be hit when the browser login is successful with an access token.

The major constituent steps are:

  • Constructing a Docker image

  • Serializing flyte objects within an instantiated container

  • Uploading the container with a latch-owned registry

  • Registering serialized objects + the container with latch.

The Docker image is constructed by inferring relevant files + dependencies from the workflow package code itself. If a Dockerfile is provided explicitly, it will be used for image construction instead.

The registration flow makes heavy use of Flyte, and while the Latch SDK modifies many components to play nicely with Latch, eg. platform API, user-specific auth, the underlying concepts are nicely summarized in the flytekit documentation.

Parameters:

pkg_root – A valid path pointing to the worklow code a user wishes to register. The path can be absolute or relative. The path is always a directory, with its structure exactly as constructed and described in the cli.services.init function.

Example

>>> register("./example_workflow")

latch_cli.services.register.utils module#

class latch_cli.services.register.utils.DockerBuildLogItem[source]#

Bases: TypedDict

message: str | None#
error: str | None#
stream: str | None#
latch_cli.services.register.utils.build_image(ctx:, image_name: str, context_path: ~pathlib.Path, dockerfile: ~pathlib.Path | None = None) → Iterable[DockerBuildLogItem][source]#
latch_cli.services.register.utils.upload_image(ctx:, image_name: str) → List[str][source]#
latch_cli.services.register.utils.serialize_pkg_in_container(ctx:, image_name: str, serialize_dir: str) → Tuple[List[str], str][source]#
latch_cli.services.register.utils.register_serialized_pkg(files: List[Path], token: str | None, version: str, workspace_id: str, latch_register_url: str = 'https://nucleus.latch.bio/sdk/register-workflow') → object[source]#
latch_cli.services.register.utils.import_module_by_path(x: Path, *, module_name: str = 'latch_metadata')[source]#

Module contents#