diff --git a/docs/introduction/core_use_cases/analytics.md b/docs/core_use_cases/analytics.md similarity index 98% rename from docs/introduction/core_use_cases/analytics.md rename to docs/core_use_cases/analytics.md index 06e2efdcaa..58b6ab770c 100644 --- a/docs/introduction/core_use_cases/analytics.md +++ b/docs/core_use_cases/analytics.md @@ -13,7 +13,7 @@ Flyte is ideal for data cleaning, statistical summarization, and plotting because with `flytekit` you can leverage the rich Python ecosystem of data processing and visualization tools. -## Cleaning Data +## Cleaning data In this example, we are going to analyze some covid vaccination data: @@ -41,7 +41,7 @@ As you can see, we're using `pandas` for data processing, and in the task below we use `plotly` to create a choropleth map of the percent of a country's population that has received at least one COVID-19 vaccination. -## Rendering Plots +## Rendering plots We can use {ref}`Flyte Decks ` for rendering a static HTML report of the map. In this case, we normalize the `people_vaccinated` by the @@ -158,7 +158,7 @@ logger.removeFilter(deck_filter) HTML(filename=cp_deck(deck_filter.deck_files["plot"])) ``` -## Custom Flyte Deck Renderers +## Custom Flyte deck renderers You can also create your own {ref}`custom Flyte Deck renderers ` to visualize data with any plotting/visualization library of your choice, as diff --git a/docs/introduction/core_use_cases/data_engineering.md b/docs/core_use_cases/data_engineering.md similarity index 98% rename from docs/introduction/core_use_cases/data_engineering.md rename to docs/core_use_cases/data_engineering.md index 941dbdbcdf..25eb802fc2 100644 --- a/docs/introduction/core_use_cases/data_engineering.md +++ b/docs/core_use_cases/data_engineering.md @@ -7,7 +7,7 @@ kernelspec: (getting_started_data_engineering)= -# Data Engineering +# Data engineering Flyte is well-suited for data engineering use cases, where you can interleave SQL queries with data processing logic implemented in Python with whichever @@ -100,7 +100,7 @@ def load(df: pd.DataFrame) -> CSVFile: return CSVFile(path=csv_file) ``` -## ETL Workflow +## ETL workflow Putting all the pieces together, we create an `etl_workflow` that produces a dataset based on the parameters you give it. @@ -130,7 +130,7 @@ csv_file = etl_workflow(limit=5) pd.read_csv(csv_file) ``` -## Workflows as Reusable Components +## Workflows as reusable components Because Flyte tasks and workflows are simply functions, we can embed `etl_workflow` as part of a larger workflow, where it's used to create a diff --git a/docs/introduction/core_use_cases/index.md b/docs/core_use_cases/index.md similarity index 84% rename from docs/introduction/core_use_cases/index.md rename to docs/core_use_cases/index.md index 5c6e634264..4ab3fa16af 100644 --- a/docs/introduction/core_use_cases/index.md +++ b/docs/core_use_cases/index.md @@ -1,8 +1,8 @@ (getting_started_core_use_cases)= -# Core Use Cases +# Core use cases -This section of the **Getting Started** documentation will take you through the +This section of the documentation will take you through the core use cases for which Flyte is designed. Within the context of these guides, we're going to assume that the discipline of data science can be broken down into at least three specializations: data engineering, machine learning (or @@ -16,9 +16,9 @@ practice. :header-rows: 0 :widths: 10 30 -* - {doc}`🛠 Data Engineering ` +* - {doc}`🛠 Data engineering ` - Create an ETL workflow for processing data with SQLAlchemy and Pandas. -* - {doc}`🤖 Machine Learning ` +* - {doc}`🤖 Machine learning ` - Train a classifier with Scikit-Learn and Pandas. * - {doc}`📈 Analytics ` - Develop a data cleaning and plotting pipeline with Plotly and Pandas. diff --git a/docs/introduction/core_use_cases/machine_learning.md b/docs/core_use_cases/machine_learning.md similarity index 96% rename from docs/introduction/core_use_cases/machine_learning.md rename to docs/core_use_cases/machine_learning.md index 04c573e1b3..78925af26f 100644 --- a/docs/introduction/core_use_cases/machine_learning.md +++ b/docs/core_use_cases/machine_learning.md @@ -7,13 +7,13 @@ kernelspec: (getting_started_machine_learning)= -# Machine Learning +# Machine learning Flyte can handle a full spectrum of machine learning workloads, from training small models to gpu-accelerated deep learning and hyperparameter optimization. -## Getting the Data +## Getting the data In this simple example, we train a binary classification model on the [wine dataset](https://scikit-learn.org/stable/datasets/toy_dataset.html#wine-dataset) @@ -34,7 +34,7 @@ def get_data() -> pd.DataFrame: return load_wine(as_frame=True).frame ``` -## Define a Training Workflow +## Define a training workflow Then, we define `process_data` and `train_model` tasks along with a `training_workflow` to put all the pieces together for a model-training @@ -76,7 +76,7 @@ type-safe launch forms on the Flyte UI. Learn more in the {ref}`Extending Flyte ` guide. ``` -## Computing Predictions +## Computing predictions Executing this workflow locally, we can call the `model.predict` method to make sure we can use our newly trained model to make predictions based on some @@ -88,7 +88,7 @@ X, _ = load_wine(as_frame=True, return_X_y=True) model.predict(X.sample(10, random_state=41)) ``` -## Extending your ML Workloads +## Extending your ML workloads There are many ways to extend your workloads: @@ -119,7 +119,7 @@ There are many ways to extend your workloads: supports ScikitLearn, TensorFlow, and PyTorch. ``` -```{admonition} Learn More +```{admonition} Learn more :class: important See the {ref}`Tutorials ` for more machine learning examples. diff --git a/docs/introduction/flyte_fundamentals/extending_flyte.md b/docs/flyte_fundamentals/extending_flyte.md similarity index 98% rename from docs/introduction/flyte_fundamentals/extending_flyte.md rename to docs/flyte_fundamentals/extending_flyte.md index db4eabe14b..4977e6ae25 100644 --- a/docs/introduction/flyte_fundamentals/extending_flyte.md +++ b/docs/flyte_fundamentals/extending_flyte.md @@ -19,7 +19,7 @@ the Flyte type system and Flyte tasks. (customizing_flyte_types)= -## Customizing Flyte Types +## Customizing Flyte types Flyte has a {ref}`rich type system ` that automatically handles the serialization and deserialization of objects so that when you pass @@ -80,7 +80,7 @@ See the {ref}`User Guide ` for an example of a custom type. ``` -## Customizing Flyte Tasks +## Customizing Flyte tasks The easiest way to extend Flyte tasks is to use Python decorators. Since Flyte tasks are simply functions, you can wrap the task function in a custom @@ -130,7 +130,7 @@ allows you to enable/disable services at the beginning/end of your workflows. See the {ref}`User Guide ` for more details. ``` -## The Plugin Hierarchy of Needs +## The plugin hierarchy of needs The decorator approach is great for many surface-level use cases, but there are many more ways to customize Flyte tasks: @@ -154,7 +154,7 @@ many more ways to customize Flyte tasks: external services like Sagemaker, Snowflake, BigQuery, etc. ``` -## What's Next? +## What's next? Congratulations! 🎉 You've just completed the Flyte Fundamentals tour. diff --git a/docs/introduction/flyte_fundamentals/index.md b/docs/flyte_fundamentals/index.md similarity index 74% rename from docs/introduction/flyte_fundamentals/index.md rename to docs/flyte_fundamentals/index.md index d810e3bcbb..a1a08fd187 100644 --- a/docs/introduction/flyte_fundamentals/index.md +++ b/docs/flyte_fundamentals/index.md @@ -1,6 +1,6 @@ (getting_started_fundamentals)= -# Flyte Fundamentals +# Flyte fundamentals This section of the documentation will take you through the fundamental concepts of Flyte: tasks, workflows, and launch plans. @@ -15,16 +15,16 @@ use cases. :header-rows: 0 :widths: 20 30 -* - {doc}`🔀 Tasks, Workflows and LaunchPlans ` +* - {doc}`🔀 Tasks, workflows and launch plans ` - Create tasks as building blocks, compose them into workflows, and schedule - them with launchplans. -* - {doc}`🗄 Registering Workflows ` + them with launch plans. +* - {doc}`🗄 Registering workflows ` - Develop and deploy workflows to a local Flyte demo cluster. -* - {doc}`⏱ Running and Scheduling Workflows ` +* - {doc}`⏱ Running and scheduling workflows ` - Execute workflows programmatically and schedule them as cron jobs. -* - {doc}`📊 Visualizing Task Input and Output ` +* - {doc}`📊 Visualizing task input and output ` - Create rich, customizable static reports for increased visibility into tasks. -* - {doc}`🏎 Optimizing Tasks ` +* - {doc}`🏎 Optimizing tasks ` - Make tasks scalable, performant, and robust to unexpected failures. * - {doc}`🔌 Extending Flyte ` - Customize Flyte types and tasks to fit your needs. @@ -42,9 +42,9 @@ cluster, see the {ref}`Deployment Guide `. :maxdepth: -1 :hidden: -tasks_and_workflows -package_register -run_schedule +tasks_workflows_and_launch_plans +registering_workflows +running_and_scheduling_workflows visualizing_task_input_and_output optimizing_tasks extending_flyte diff --git a/docs/introduction/flyte_fundamentals/optimizing_tasks.md b/docs/flyte_fundamentals/optimizing_tasks.md similarity index 98% rename from docs/introduction/flyte_fundamentals/optimizing_tasks.md rename to docs/flyte_fundamentals/optimizing_tasks.md index 0f8057dc55..508767d05f 100644 --- a/docs/introduction/flyte_fundamentals/optimizing_tasks.md +++ b/docs/flyte_fundamentals/optimizing_tasks.md @@ -7,7 +7,7 @@ kernelspec: (getting_started_optimizing_tasks)= -# Optimizing Tasks +# Optimizing tasks There are many ways to optimize your tasks and workflows in Flyte, and this guide will take you through some of the common methods for doing so. @@ -94,7 +94,7 @@ def compute_mean(data: List[float]) -> float: Notice that the `timeout` argument takes a built-in Python {py:class}`~datetime.timedelta` object. -## Map Tasks +## Map tasks If you need to parallelize a task, you can use the {py:func}`~flytekit.map_task` construct. A mappable task is one that takes in a single argument and produces @@ -145,7 +145,7 @@ def parallelized_compute_mean(data: List[float], n_partitions: int = 10) -> floa parallelized_compute_mean(data=[float(x) for x in range(10_000)]) ``` -## Resource Allocation +## Resource allocation As one of the core features of Flyte, workflows can be composed of tasks that potentially have heterogeneous resource requirements. You can express this with @@ -165,7 +165,7 @@ def heavy_task() -> float: ... ``` -## Multi-image Workflows +## Multi-image workflows In addition to task-level resource configuration, you can also specify different images per task. This is particularly useful if some @@ -211,7 +211,7 @@ You can also configure the container images dynamically. See the ``` -## Declarative Infrastructure +## Declarative infrastructure Finally, staying with the theme of Flyte's ability to handle heterogeneous workloads at the most granular level, you can configure tasks to leverage @@ -252,7 +252,7 @@ so its plugin system enables you to call out to third-party services and infrastructure when needed so that you can embed existing workloads into the Flyte programming paradigm. -## What's Next? +## What's next? In this guide, you learned the various ways in which you can optimize your tasks and workflows to make them more scalable and robust. In the final stop of diff --git a/docs/introduction/flyte_fundamentals/package_register.md b/docs/flyte_fundamentals/registering_workflows.md similarity index 97% rename from docs/introduction/flyte_fundamentals/package_register.md rename to docs/flyte_fundamentals/registering_workflows.md index 0116fa625e..4e2186df7f 100644 --- a/docs/introduction/flyte_fundamentals/package_register.md +++ b/docs/flyte_fundamentals/registering_workflows.md @@ -1,6 +1,6 @@ (getting_started_package_register)= -# Registering Workflows +# Registering workflows In this guide, you'll learn how to package and register (that is, deploy) your tasks and workflows to a Flyte cluster. This will enable you to scale your workloads with @@ -17,7 +17,7 @@ This guide assumes that you: guide to create a minimal Flyte project. ``` -## Custom Dependencies +## Custom dependencies If you have custom Python dependencies, update the `requirements.txt` file that ships with the {ref}`project template ` @@ -27,7 +27,7 @@ You can also update the Dockerfile (if using a Dockerfile) or the [ImageSpec con want to use a different base image or if the additional Python dependencies require installing binaries or packages from other languages. -# Registration Patterns +## Registration patterns There are different methods of registering your workflows to a Flyte cluster where each method fulfills a particular use case during the workflow development @@ -45,7 +45,7 @@ The following diagram provides a summarized view of the different registration p (getting_started_register_pyflyte_run)= -## Iterating on a Single Task or Workflow +## Iterating on a single task or workflow The quickest way to register a task or workflow to a Flyte cluster is with the `pyflyte run` CLI command. Assuming that you're inside the `my_project` directory @@ -80,7 +80,7 @@ contain additional tasks or workflows. (getting_started_pyflyte_register)= -### Iterating on a Flyte Project +### Iterating on a Flyte project One of Flyte's benefits is its functional design, which means that you can import and reuse tasks and workflows like you would Python functions when you @@ -137,7 +137,7 @@ Once you've successfully registered your workflows, you can execute them by going to the Flyte console. If you're using a local Flyte demo cluster, you can go to the browser at `localhost:30080/console` and do the following: - - Navigate to the **flytesnacks** > **development** domain. +- Navigate to the **flytesnacks** > **development** domain. - Click on the **Workflows** section of the left-hand sidebar. - Click on the **workflows.example.wf** card on the workflows list. - Click on the **Launch Workflow** button on the top-right corner. @@ -149,7 +149,7 @@ go to the browser at `localhost:30080/console` and do the following: In the next guide you'll learn about how to run your workflows programmatically. ``` -#### Fast Registration +#### Fast registration `pyflyte register` packages up your code through a mechanism called **fast registration**. Fast registration is useful when you already have a @@ -182,7 +182,7 @@ You can do so by specifying these files in a `.gitignore` or `.dockerignore` file in the root directory of your project. ``` -### Productionizing your Workflows +### Productionizing your workflows Flyte's core design decision is to make workflows reproducible and repeatable. One way it achieves this is by providing a way for you to bake-in user-defined @@ -200,7 +200,7 @@ are immutable. (containerizing_your_project)= -#### Containerizing your Project +#### Containerizing your project Flyte relies on OCI-compatible containers to package up your code and third-party dependencies. When you invoke `pyflyte init`, the resulting template project @@ -242,7 +242,7 @@ docker login ghcr.io docker push ``` -```{admonition} Pulling Private Images +```{admonition} Pulling private images :class: important For many projects it's convenient to make your images public, but in the case @@ -252,7 +252,7 @@ metadata/configuration, it's more secure if they're private. Learn more about how to pull private image in the {ref}`User Guide `. ``` -#### Package your Project with `pyflyte package` +#### Package your project with `pyflyte package` You can package your project with the `pyflyte package` command like so: @@ -350,7 +350,7 @@ two GitHub actions that facilitates this: of Flyte packages, for example, the `.tgz` archives that are created by `pyflyte package`. -## What's Next? +## What's next? In this guide, you learned about the Flyte demo cluster, Flyte configuration, and the different registration patterns you can leverage during the workflow diff --git a/docs/introduction/flyte_fundamentals/run_schedule.md b/docs/flyte_fundamentals/running_and_scheduling_workflows.md similarity index 92% rename from docs/introduction/flyte_fundamentals/run_schedule.md rename to docs/flyte_fundamentals/running_and_scheduling_workflows.md index e4a1f98470..60bbe98596 100644 --- a/docs/introduction/flyte_fundamentals/run_schedule.md +++ b/docs/flyte_fundamentals/running_and_scheduling_workflows.md @@ -7,7 +7,7 @@ kernelspec: (getting_started_run_and_schedule)= -# Running and Scheduling Workflows +# Running and scheduling workflows Flyte supports the development and debugging of tasks and workflows in a local setting, which increases the iteration speed of building out your data- @@ -28,7 +28,7 @@ This guide assumes that you've completed the previous guides for {ref}`Packaging and Registering Workflows `. ``` -## Create a `FlyteRemote` Object +## Create a `FlyteRemote` object In {doc}`"Running a workflow locally" <../getting_started_with_workflow_development/running_a_workflow_locally>`, you saw how to run Flyte workflows with `pyflyte run` in the case that you're working @@ -52,7 +52,7 @@ remote = FlyteRemote( ) ``` -## Running a Workflow +## Running a workflow You can run workflows using the `FlyteRemote` {py:meth}`~flytekit.remote.remote.FlyteRemote.execute` method, where you need to pass in a dictionary of `inputs` that adhere to the @@ -60,7 +60,7 @@ interface defined by the workflow. `````{tabs} -````{group-tab} Locally Imported +````{group-tab} Locally imported If you have access to the `@workflow`-decorated function in your Python runtime environment, you can import and execute it directly: @@ -83,7 +83,7 @@ execution = remote.execute( ```` -````{group-tab} Remotely Fetched +````{group-tab} Remotely fetched Execute a workflow by fetching a `FlyteWorkflow` object from the remote **FlyteAdmin** service, which essentially contains the metadata representing a @@ -103,13 +103,13 @@ You can also launch workflows via `flytectl` which you can learn more about in the {ref}`User Guide `. ``` -## Running a Launchplan +## Running a launch plan Similar to workflows, you can run launch plans with `FlyteRemote`: `````{tabs} -````{group-tab} Locally Imported +````{group-tab} Locally imported If you have a `LaunchPlan` defined in your Python runtime environment, you can execute it directly: @@ -127,7 +127,7 @@ execution = remote.execute(launch_plan, inputs={}) ```` -````{group-tab} Remotely Fetched +````{group-tab} Remotely fetched Execute a task by fetching a `FlyteLaunchPlan` object from the remote **FlyteAdmin** service, which essentially contains the metadata representing a @@ -145,13 +145,13 @@ execution = remote.execute(flyte_launchplan, inputs={}) ````` -## Running a Task +## Running a task You can also run individual tasks on a Flyte cluster using `FlyteRemote`: `````{tabs} -````{group-tab} Locally Imported +````{group-tab} Locally imported If you have access to the `@task`-decorated function in your Python runtime environment, you can import and execute it directly: @@ -165,7 +165,7 @@ execution = remote.execute(say_hello, inputs={"name": "Kermit"}) ```` -````{group-tab} Remotely Fetched +````{group-tab} Remotely fetched Execute a task by fetching a `FlyteWorkflow` object from the remote **FlyteAdmin** service, which essentially contains the metadata representing a @@ -184,13 +184,13 @@ execution = remote.execute(flyte_task, inputs={"name": "Kermit"}) You can also launch tasks via `flytectl`, learn more in the {ref}`User Guide ` ``` -## Fetching Inputs and Outputs of an Execution +## Fetching inputs and outputs of an execution By default, {py:meth}`FlyteRemote.execute ` is non-blocking, but you can also pass in `wait=True` to make it synchronously wait for the task or workflow to complete. -Print out the Flyte console url corresponding to your execution with: +Print out the Flyte console URL corresponding to your execution with: ```{code-block} python print(f"Execution url: {remote.generate_console_url(execution)}") @@ -212,7 +212,7 @@ completed_execution = remote.wait(execution) print(completed_execution.outputs) # print out the outputs ``` -## Scheduling a Launch Plan +## Scheduling a launch plan Finally, you can create a {py:class}`~flytekit.LaunchPlan` that's scheduled to run at a particular cadence by specifying the `schedule` argument: @@ -247,7 +247,7 @@ launch_plan = LaunchPlan.get_or_create( ) ``` -### Passing in the Scheduled Kick-off Time +### Passing in the scheduled kick-off time Suppose that your workflow is parameterized to take in a `datetime` argument, which determines how the workflow is executed (e.g. reading in data using the @@ -276,13 +276,13 @@ process_data_lp = LaunchPlan.get_or_create( ) ``` -### Registering Launch Plans +### Registering launch plans -Any of the methods described in the {doc}`package_register` guide will register +Any of the methods described in the {doc}`registering_workflows` guide will register a launchplan as long as it's defined in any of the Python modules that you want to register to a Flyte backend. -### Activating a Schedule +### Activating a schedule Once you've registered your launch plan, You can use the `FlyteRemote` client or the `flytectl` CLI to activate the schedule: @@ -309,7 +309,7 @@ flytectl update launchplan -p flyteexamples -d development \ ::::: -### Deactivating a Schedule +### Deactivating a schedule Similarly, you can deactivate a launchplan with: @@ -335,7 +335,7 @@ flytectl update launchplan -p flyteexamples -d development \ ::::: -## What's Next? +## What's next? In this guide, you learned about how to: diff --git a/docs/introduction/flyte_fundamentals/tasks_and_workflows.md b/docs/flyte_fundamentals/tasks_workflows_and_launch_plans.md similarity index 94% rename from docs/introduction/flyte_fundamentals/tasks_and_workflows.md rename to docs/flyte_fundamentals/tasks_workflows_and_launch_plans.md index fb16e85959..c8ca7f2071 100644 --- a/docs/introduction/flyte_fundamentals/tasks_and_workflows.md +++ b/docs/flyte_fundamentals/tasks_workflows_and_launch_plans.md @@ -7,7 +7,7 @@ kernelspec: (getting_started_tasks_and_workflows)= -# Tasks, Workflows and LaunchPlans +# Tasks, workflows and launch plans In {doc}`"Getting started with workflow development" <../getting_started_with_workflow_development/index>`, we got a basic sense of how Flyte works by creating and running a workflow made up of a few tasks. @@ -18,7 +18,7 @@ programming model. Flyte tasks are the core building blocks of larger, more complex workflows. -### Tasks are Containerized Blocks of Compute +### Tasks are containerized blocks of compute You can think of a Flyte task as a containerized block of compute. When a task runs on a Flyte backend, it's isolated within its own container, separate from @@ -51,7 +51,7 @@ There are three important things to note here: Flyte orchestrates what task to run at what time in the context of a workflow. ``` -### Tasks are Strongly Typed +### Tasks are strongly typed You might also notice that the `mean` function signature is type-annotated with Python type hints. Flyte uses these annotations to check the input and output @@ -88,7 +88,7 @@ of computation to produce some useful set of outputs or outcomes. Suppose the `mean` task is just one building block of a larger computation. This is where Flyte workflows can help us manage the added complexity. -### Workflows Build Execution Graphs +### Workflows build execution graphs Suppose that we want to mean-center and standard-deviation-scale a set of values. In addition to a `mean` function, we also need to compute standard @@ -130,7 +130,7 @@ standard_scale_workflow(values=[float(i) for i in range(1, 11)]) (workflows_versus_task_syntax)= -### Workflows versus Tasks Under the Hood +### Workflows versus tasks under the hood Although Flyte workflow syntax looks like Python code, it's actually a [domain-specific language (DSL)](https://en.wikipedia.org/wiki/Domain-specific_language) @@ -153,7 +153,7 @@ In contrast to workflow code, the code within tasks is actually executed by a Python interpreter when it's run locally or inside a container when run on a Flyte cluster. -### Workflows Deal with Promises +### Workflows deal with promises A promise is essentially a placeholder for a value that hasn't been materialized yet. To show you what this means concretely, let's re-define @@ -177,7 +177,7 @@ _it doesn't actually run the computations yet_. Therefore, when Flyte compiles a workflow, the outputs of task calls are actually promises and not regular python values. -### Workflows are Strongly Typed Too +### Workflows are strongly typed too Since both tasks and workflows are strongly typed, Flyte can actually catch type errors! When we learn more about packaging and registering in the next few @@ -208,7 +208,7 @@ except Exception as e: print(e) ``` -### Workflows can be Embedded in Other Workflows +### Workflows can be embedded in other workflows When a workflow uses another workflow as part of the execution graph, we call the inner workflow a **subworkflow**. Subworkflows are strongly typed and can @@ -238,7 +238,7 @@ workflow_with_subworkflow(num_samples=10, seed=3) Learn more about subworkflows in the {ref}`User Guide `. ``` -### Specifying Dependencies without Passing Data +### Specifying dependencies without passing data You can also specify dependencies between tasks and subworkflows without passing data from the upstream entity to the downstream entity using the `>>` right shift @@ -269,7 +269,7 @@ the {py:func}`~functools.partial` function in the Python standard library where you can define default (overridable) and fixed (non-overridable) inputs. ```{note} -Additionally, `LaunchPlan`s provides an interface for specifying run-time +Additionally, `LaunchPlan` provides an interface for specifying run-time overrides such as notifications, schedules, and more. ``` @@ -285,9 +285,9 @@ standard_scale_launch_plan = LaunchPlan.get_or_create( ) ``` -### Invoking LaunchPlans Locally +### Invoking launch plans locally -You can run a `LaunchPlan` locally. This is, using the local Python interpreter (REPL). It will use the `default_inputs` dictionary +You can run a launch plan locally. This is, using the local Python interpreter (REPL). It will use the `default_inputs` dictionary whenever it's invoked: ```{code-cell} ipython3 @@ -305,7 +305,7 @@ the time being you can think of them as a way for you to templatize workflows for some set of related use cases, such as model training with a fixed dataset for reproducibility purposes. -### LaunchPlans can be Embedded in Workflows +### Launch plans can be embedded in workflows Similar to subworkflows, launch plans can be used in a workflow definition: @@ -327,7 +327,7 @@ context of the parent workflow's execution context. Learn more about subworkflows in the {ref}`User Guide `. ``` -## What's Next? +## What's next? So far we've been working with small code snippets and self-contained scripts. Next, we'll see how to organize a Flyte project that follows software diff --git a/docs/introduction/flyte_fundamentals/visualizing_task_input_and_output.md b/docs/flyte_fundamentals/visualizing_task_input_and_output.md similarity index 97% rename from docs/introduction/flyte_fundamentals/visualizing_task_input_and_output.md rename to docs/flyte_fundamentals/visualizing_task_input_and_output.md index 928a0cd2bc..487d1627c9 100644 --- a/docs/introduction/flyte_fundamentals/visualizing_task_input_and_output.md +++ b/docs/flyte_fundamentals/visualizing_task_input_and_output.md @@ -20,9 +20,9 @@ tabs. By default, every task has three decks: an **input**, an **output**, and a Flyte materializes Decks via `Renderer`s, which are specific implementations of how to generate an HTML report from some Python object. -## Enabling Flyte Decks +## Enabling Flyte decks -To enable Flyte Decks, simply set `disable_deck=False` in the `@task` decorator: +To enable Flyte decks, simply set `disable_deck=False` in the `@task` decorator: ```{code-cell} ipython3 import pandas as pd @@ -37,7 +37,7 @@ def iris_data() -> pd.DataFrame: Specifying this flag indicates that Decks should be rendered whenever this task is invoked. -## Rendering Task Inputs and Outputs +## Rendering task inputs and outputs By default, Flyte will render the inputs and outputs of tasks with the built-in renderers in the corresponding **input** and **output** {py:class}`~flytekit.deck.Deck`s, @@ -153,7 +153,7 @@ to `20`. Doing so will emit logs that look like the above print statement, where the `deck.html` filepath can be found in the `message` key. ``` -## Rendering In-line Decks +## Rendering in-line decks You can render Decks inside the task function body by using the **default** deck, which you can access with the {py:func}`~flytekit.current_context` @@ -191,7 +191,7 @@ should contain the markdown text we specified. (getting_started_customer_renderers)= -## Custom Renderers +## Custom renderers What if we don't want to show raw data values in the Flyte Deck? We can create a pandas dataframe renderer that summarizes the data instead of showing raw values @@ -283,7 +283,7 @@ into some HTML representation. Learn more about Flyte Decks in the {ref}`User Guide `. ``` -## What's Next? +## What's next? In this guide, you learned how to generate static HTML reports to gain more visibility into Flyte tasks. In the next guide, you'll learn how to optimize diff --git a/docs/introduction/getting_started_with_workflow_development/creating_a_flyte_project.md b/docs/getting_started_with_workflow_development/creating_a_flyte_project.md similarity index 100% rename from docs/introduction/getting_started_with_workflow_development/creating_a_flyte_project.md rename to docs/getting_started_with_workflow_development/creating_a_flyte_project.md diff --git a/docs/introduction/getting_started_with_workflow_development/flyte_project_components.md b/docs/getting_started_with_workflow_development/flyte_project_components.md similarity index 100% rename from docs/introduction/getting_started_with_workflow_development/flyte_project_components.md rename to docs/getting_started_with_workflow_development/flyte_project_components.md diff --git a/docs/introduction/getting_started_with_workflow_development/index.md b/docs/getting_started_with_workflow_development/index.md similarity index 100% rename from docs/introduction/getting_started_with_workflow_development/index.md rename to docs/getting_started_with_workflow_development/index.md diff --git a/docs/introduction/getting_started_with_workflow_development/installing_development_tools.md b/docs/getting_started_with_workflow_development/installing_development_tools.md similarity index 100% rename from docs/introduction/getting_started_with_workflow_development/installing_development_tools.md rename to docs/getting_started_with_workflow_development/installing_development_tools.md diff --git a/docs/introduction/getting_started_with_workflow_development/running_a_workflow_locally.md b/docs/getting_started_with_workflow_development/running_a_workflow_locally.md similarity index 100% rename from docs/introduction/getting_started_with_workflow_development/running_a_workflow_locally.md rename to docs/getting_started_with_workflow_development/running_a_workflow_locally.md diff --git a/docs/index.md b/docs/index.md index 162d36af06..3a8d38e6ba 100644 --- a/docs/index.md +++ b/docs/index.md @@ -76,7 +76,7 @@ contribute its architecture and design. You can also access the :header-rows: 0 :widths: 20 30 -* - {doc}`🔤 Introduction to Flyte ` +* - {doc}`🔤 Introduction to Flyte ` - Get your first workflow running, learn about the Flyte development lifecycle and core use cases. * - {doc}`📖 User Guide ` @@ -134,11 +134,11 @@ Have questions or need support? The best way to reach us is through Slack: :maxdepth: 1 :hidden: -Introduction -Quickstart guide -Getting started with workflow development -Flyte Fundamentals -Core Use Cases +Introduction +Quickstart guide +Getting started with workflow development +Flyte fundamentals +Core use cases ``` ```{toctree} diff --git a/docs/introduction/index.md b/docs/introduction.md similarity index 100% rename from docs/introduction/index.md rename to docs/introduction.md diff --git a/docs/introduction/quickstart_guide.md b/docs/quickstart_guide.md similarity index 100% rename from docs/introduction/quickstart_guide.md rename to docs/quickstart_guide.md