Command Line Interfaces and Clients

Flytekit currently ships with two CLIs, both of which rely on the same client implementation code.

Clients

The client code is located in flytekit/clients and there are two.

  • Similar to the Model Files files, but a bit more complex, the raw one is basically a wrapper around the Protobuf generated code, with some handling for authentication in place, and acts as a mechanism for autocompletion and comments.

  • The friendly client uses the raw client, adds handling of things like pagination, and is structurally more aligned with the functionality and call pattern of the CLI itself.

class flytekit.clients.friendly.SynchronousFlyteClient(url, insecure=False, credentials=None, options=None)[source]

This is a low-level client that users can use to make direct gRPC service calls to the control plane. See the service spec. This is more user-friendly interface than the raw client so users should try to use this class first. Create a client by

SynchronousFlyteClient("your.domain:port", insecure=True)
# insecure should be True if your flyteadmin deployment doesn't have SSL enabled

Initializes a gRPC channel to the given Flyte Admin service.

Parameters

  • url (Text) – The URL (including port if necessary) to connect to the appropriate Flyte Admin Service.

  • insecure (bool) – [Optional] Whether to use an insecure connection, default False

  • credentials (Text) – [Optional] If provided, a secure channel will be opened with the Flyte Admin Service.

  • options (dict[Text, Text]) – [Optional] A dict of key-value string pairs for configuring the gRPC core runtime.

  • metadata (list[(Text,Text)]) – [Optional] metadata pairs to be transmitted to the service-side of the RPC.

class flytekit.clients.raw.RawSynchronousFlyteClient(url, insecure=False, credentials=None, options=None)[source]

This is a thin synchronous wrapper around the auto-generated GRPC stubs for communicating with the admin service.

This client should be usable regardless of environment in which this is used. In other words, configurations should be explicit as opposed to inferred from the environment or a configuration file.

Initializes a gRPC channel to the given Flyte Admin service.

Parameters

  • url (Text) – The URL (including port if necessary) to connect to the appropriate Flyte Admin Service.

  • insecure (bool) – [Optional] Whether to use an insecure connection, default False

  • credentials (Text) – [Optional] If provided, a secure channel will be opened with the Flyte Admin Service.

  • options (dict[Text, Text]) – [Optional] A dict of key-value string pairs for configuring the gRPC core runtime.

  • metadata (list[(Text,Text)]) – [Optional] metadata pairs to be transmitted to the service-side of the RPC.

Command Line Interfaces

Flyte CLI

flyte-cli is the general CLI that can be used to talk to the Flyte control plane (Flyte Admin). It ships with flytekit as part of the Pypi package. Think of this as the kubectl for Flyte. In fact, we’re working on flytectl which is under active development the completion of which will deprecate this CLI.

Think of this CLI as a network-aware (i.e. can talk to Admin) but not code-aware (doesn’t need to have user code checked out) CLI. In the registration flow, this CLI is responsible for shipping the compiled Protobuf files off to Flyte Admin.

Pyflyte

Unlike Flyte CLI, think of this CLI as code-aware, but not network-aware (the latter is not entirely true, but it’s helpful to think of it that way).

This CLI is what is responsible for the serialization (compilation) step in the registration flow. It will parse through user code, looking for tasks, workflows and launch plans, and compile them down to Protobuf files.