run

class pcs.run.Run(experiment_id: Optional[str] = None, existing_run_id: Optional[str] = None)

Conceptually, a Run represents code execution. More specifically, a Run has two distinct uses. First, a Run is used to document an instance of code execution and record output associated with it (similar to a logger). Second, a Run allows for reproducibility. For this a Run can optionally hold a RunCommand that can be used to recreate this run, i.e., to perform a “re-run”.

We implement a Run that records its RunCommand as a special type of Run called a :py.func.pcs.run_command.ComponentRun: which is a subclass of Run.

A Run is similar to a logger but provides a bit more structure than loggers traditionally do. For example, instead of just a log-level and some free text, which is the typical interface for a logger, a Run allows recording of tags, parameters, and metrics. These each have their own semantics and each is represented as a key-value pair. Currently, an AgentOS Run is a wrapper around an MLflow Run.

An MLflow Run is a thin container that holds an RunData and RunInfo object. RunInfo contains the run metadata (id, user, timestamp, etc.) RunData contains metrics, params, and tags; each of which is a dict.

AgentOS Run related abstractions are encoded into an MLflowRun as follows: - Component Registry -> MLflow artifact file - Entry point string -> MLflow run tag (MlflowRun.data.tags entry) - ArgumentSet -> MLflow artifact file

A Run can also contain a [pointer to a] RunCommand.

A Run can also have pointers to other runs. These pointers can have different semantic meanings. They could have an “inner-outer” relationship, i.e., an outer run is already active when it’s “inner” run starts and ends. Alternatively, two runs could have an “output-input dependency-depender” relationship, in which the depender uses the some part of dependency run’s output as input. In this case, the relationship is causal.

DEFAULT_EXPERIMENT_ID = '0'

PASS_THROUGH_FN_PREFIXES = ['log', 'set_tag', 'list_artifacts', 'search_runs', 'set_terminated', 'download_artifacts']

PCS_RUN_TAG = 'pcs.is_run'

__init__(experiment_id: Optional[str] = None, existing_run_id: Optional[str] = None) → None

Run initialization can either create a new underlying MLflowRun or be be based on an existing underlying MLflowRun.

If Python gracefully supported overloading constructors, it would make this code a lot more easy to comprehend, but as it is __init__() handles both cases by inspecting which arguments are provided.

Because of this, we recommend using class factory methods instead of directly using __init__(). For example: Run.from_run_command(), Run.from_existing_run_id().

Parameters

• experiment_id – Optional Experiment ID.

• existing_run_id – Optional Run ID.

property data: dict

end(status: str = 'FINISHED') → None

This is copied and adapted from MLflow’s fluent api mlflow.end_run

classmethod from_existing_run_id(run_id: str) → pcs.run.Run

classmethod from_registry(registry: pcs.registry.Registry, run_id: str) → pcs.run.Run

classmethod get_all_runs()

property identifier: str

property info: dict

static print_all_status() → None

print_status(detailed: bool = False) → None

classmethod run_exists(run_id) → bool

to_registry(registry: Optional[pcs.registry.Registry] = None, force: bool = False, include_artifacts: bool = False) → pcs.registry.Registry

to_spec(flatten: bool = False) → Mapping