latch_cli.services package#

Subpackages#

Submodules#

latch_cli.services.execute module#

latch_cli.services.get module#

Service to get workflows.

latch_cli.services.get.get_wf(wf_name: str | None = None)[source]#

Get a list of a workflow’s versions.

This will allow users to list all owned workflows by default. Optionally, a user can provide a workflow name (unique with respect to a user) to list all versions of the specific workflow.

Parameters:

wf_name – The name of the workflow.

Example

>>> get_wf("wf.__init__.alphafold_wf")
    ID      Name                            Version
    61858   wf.__init__.alphafold_wf        v2.1.0+14
    67261   wf.__init__.alphafold_wf        v2.2.3+0
    67317   wf.__init__.alphafold_wf        v2.2.3+14
    67341   wf.__init__.alphafold_wf        v2.2.3+19
    67408   wf.__init__.alphafold_wf        v2.2.3+40
    ...

latch_cli.services.get_executions module#

latch_cli.services.get_executions.get_executions()[source]#

Open an interactive terminal user interface that shows all executions for a particular user on Latch.

This function in many ways mimics the interface at https://console.latch.bio but in a terminal. You may scroll around using either the arrow keys (or [HJKL] if you like Vim) and you can hit [ENTER] to see more information about the selected execution. You can see logs, and abort a running execution.

This function should only be called from the CLI, as doing so in any other setting will likely cause the interface to behave in an unexpected way.

latch_cli.services.get_params module#

latch_cli.services.get_params.get_params(wf_name: str, wf_version: str | None = None)[source]#

Constructs a parameter map for a workflow given its name and an optional version.

This function creates a python parameter file that can be used by launch. You can specify the specific parameters by editing the file, and then launch an execution on Latch using those parameters with launch.

Parameters:
  • wf_name – The unique name of the workflow.

  • wf_version – An optional workflow version. If this argument is not given, get_params will default to generating a parameter map of the most recent version of the workflow.

Example

>>> get_params("wf.__init__.alphafold_wf")
    # creates a file called `wf.__init__.alphafold_wf.params.py` that
    # contains a template parameter map.

latch_cli.services.launch module#

Service to launch a workflow.

latch_cli.services.launch.launch(params_file: Path, version: str | None = None) str[source]#

Launches a (versioned) workflow with parameters specified in python.

Using a parameter map written in python (this can be generated for you with get_params), this function will launch the workflow specified in the file using the parameters therein. This function also accepts an optional version parameter to further specify the workflow to be run. If it is not provided, this function will default to running the latest version of the specified workflow.

Parameters:
  • params_file – A path pointing to a python parameter file containing a function call that represents the workflow execution with valid parameter values.

  • version – An optional workflow version to launch, defaulting to the latest if not provided.

Returns:

The name of the workflow.

Example

>>> launch(Path("wf.__init__.assemble_and_sort.params.py"))
    # Launches an execution of `wf.__init__.assemble_and_sort` with the
    # parameters specified in the referenced file.

latch_cli.services.local_dev module#

class latch_cli.services.local_dev.TaskSize(value, names=None, *, module=None, qualname=None, type=None, start=1, boundary=None)[source]#

Bases: str, Enum

small_task = 'small_task'#
medium_task = 'medium_task'#
large_task = 'large_task'#
small_gpu_task = 'small_gpu_task'#
large_gpu_task = 'large_gpu_task'#
latch_cli.services.local_dev.rsync(pkg_root: Path, ip: str, ssh_command: str, cancel_event: Event)[source]#
latch_cli.services.local_dev.local_development(pkg_root: Path, *, skip_confirm_dialog: bool = False, size: TaskSize | None = None, image: str | None = None)[source]#

Starts a REPL that allows a user to interactively run tasks to help with debugging during workflow development.

In this REPL, you can run tasks or scripts and make edits to them without having to reregister your workflow. You can also get a shell into a container with the same environment as the one that the workflow runs in, to help debug installation issues. See the full documentation for Local Development for more info.

Like get_executions, this should only be called from the CLI for best results.

Parameters:

pkg_root – A path that points to a valid workflow directory (see the docs for register)

latch_cli.services.local_dev_old module#

latch_cli.services.local_dev_old.local_development(pkg_root: Path, snakemake: bool)[source]#

Starts a REPL that allows a user to interactively run tasks to help with debugging during workflow development.

In this REPL, you can run tasks or scripts and make edits to them without having to reregister your workflow. You can also get a shell into a container with the same environment as the one that the workflow runs in, to help debug installation issues. See the full documentation for Local Development for more info.

Like get_executions, this should only be called from the CLI for best results.

Parameters:

pkg_root – A path that points to a valid workflow directory (see the docs for register)

latch_cli.services.login module#

Service to login.

latch_cli.services.login.login(connection: str | None = None) str[source]#

Authenticates a user with Latch and persists an access token.

Kicks off the three-legged OAuth2.0 flow outlined in this RFC. The logic scaffolding this flow and detailed documentation about it can be found in the latch.auth package.

The user will be redirected to a browser and prompted to login. This function meanwhile spins up a callback server on a separate thread that will be hit when the browser login is successful with an access token.

latch_cli.services.ls module#

Service to list files in a remote directory.

latch_cli.services.ls.ls(path: str, *, group_directories_first: bool = False)[source]#

Lists the children of a remote directory in Latch.

Parameters:
  • path – A valid remote path

  • group_directories_first – Option to display directories/links before objects

This function will list all of the entites under the remote directory specified in the path path. Will error if the path is invalid or the directory doesn’t exist.

Examples

>>> ls("")
    # Lists all entities in the user's root directory
>>> ls("latch:///dir1/dir2/dir_name")
    # Lists all entities inside dir1/dir2/dir_name

latch_cli.services.move module#

latch_cli.services.move.move(src: str, dest: str, *, no_glob: bool = False)[source]#

latch_cli.services.open_file module#

latch_cli.services.preview module#

latch_cli.services.preview.preview(pkg_root: Path)[source]#

Generate a preview of the parameter interface for a workflow.

This will allow a user to see how their parameter interface will look without having to first register their workflow.

Parameters:

pkg_root – A valid path pointing to the worklow code a user wishes to preview. The path can be absolute or relative.

Example

>>> preview("wf.__init__.alphafold_wf")

latch_cli.services.stop_pod module#

latch_cli.services.stop_pod.stop_pod(pod_id: int) None[source]#

Stops a pod given a pod_id

latch_cli.services.sync module#

latch_cli.services.sync.upload_file(src: Path, dest: str)[source]#
latch_cli.services.sync.check_src(p: Path, *, indent: str = '') Tuple[Path, stat_result] | None[source]#
latch_cli.services.sync.sync_rec(srcs: Dict[str, Tuple[Path, stat_result]], dest: str, *, delete: bool, level: int = 0)[source]#
latch_cli.services.sync.sync(srcs_raw: List[str], dest: str, *, delete: bool, ignore_unsyncable: bool)[source]#

latch_cli.services.workspace module#

class latch_cli.services.workspace.WSInfo[source]#

Bases: TypedDict

workspace_id: str#
name: str#
latch_cli.services.workspace.workspace()[source]#

Opens a terminal user interface in which a user can select the workspace the want to switch to.

Like get_executions, this function should only be called from the CLI.

Module contents#

Services or actions exposed through the SDK.

Services take one or more domain objects and/or values and perform some transformation. These are the actions a user will interact with through the CLI, eg. to “register” a workflow given login context.