[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1066812851 ## docs/apache-airflow/public-airflow-interface.rst: ## @@ -0,0 +1,374 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +... + +The Public Interface of Apache Airflow is a set of interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This includes operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +and for automating certain aspects of the Airflow workflow. + +Using Airflow Public Interfaces +=== + +Using Airflow Public Interfaces is needed when you want to interact with Airflow programmatically: + +* When you are writing new (or extending existing) custom Python classes (Operators, Hooks) - basic building + blocks of DAGs and can be done DAG Authors to add missing functionality in their DAGs or by those who write + reusable custom operators for other DAG authors. +* When writing new :doc:`Plugins ` that extend Airflow's functionality beyond + DAG building blocks. Secrets, Timetables, Triggers, Listeners are all examples of such functionality. This + is usually done by users who manage Airflow instances. +* Bundling custom Operators, Hooks, Plugins and releasing them together via + :doc:`provider packages ` - this is usually done by those who intend to + provide reusable set of functionality for external service or application Airflow integrates with. + +All the ways above involve extending or using Airflow Python classes and functions. The classes +and functions mentioned below can be relied to keep backwards-compatible signatures and behaviours within +MAJOR version of Airflow. On the other hand, classes and method started with ``_`` (also known +as protected Python methods) and ``__`` (also known as private Python methods) are not part of the Public +Airflow Interface and might change any time. + +You can also use Airflow's Public Interface via the `Stable REST API `_ (based on the +OpenAPI specification). For specific needs you can also use the +`Airflow Command Line Interface (CLI) `_ though it's behaviour might change +in details (such as output format and available flags) so if you want to rely on those in programmatic +way, the Stable REST API is recommended. + + +Using Public Interface by DAG Authors += + +DAGS + + +The DAG is Airflow's core entity that represents a recurring workflow. You can create a DAG by +instantiating the :class:`~airflow.models.dag.DAG` class in your DAG file. + +Airflow has a set of Example DAGs that you can use to learn how to write DAGs + +.. toctree:: + :includehidden: + :glob: + :maxdepth: 1 + + _api/airflow/example_dags/index + +You can read more about DAGs in :doc:`DAGs `. + +.. _pythonapi:operators: + +Operators +- + +Operators allow for generation of certain types of tasks that become nodes in +the DAG when instantiated. + +There are 3 main types of operators: + +- Operators that performs an **action**, or tell another system to + perform an action +- **Transfer** operators move data from one system to another +- **Sensors** are a certain type of operator that will keep running until a + certain criterion is met. Examples include a specific file landing in HDFS or + S3, a partition appearing in Hive, or a specific time of the day. Sensors + are derived from :class:`~airflow.sensors.base.BaseSensorOperator` and run a poke + method at a specified :attr:`~airflow.sensors.base.BaseSensorOperator.poke_interval` until it + returns ``True``. + +All operators are derived from :class:`~airflow.models.baseoperator.BaseOperator` and acquire much +functionality through inheritance. Since this is the core of the engine, +it's worth taking the time to understand the parameters of :class:`~airflow.models.baseope
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1066811953 ## docs/apache-airflow/public-airflow-interface.rst: ## @@ -0,0 +1,374 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +... + +The Public Interface of Apache Airflow is a set of interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This includes operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +and for automating certain aspects of the Airflow workflow. + +Using Airflow Public Interfaces +=== + +Using Airflow Public Interfaces is needed when you want to interact with Airflow programmatically: + +* When you are writing new (or extending existing) custom Python classes (Operators, Hooks) - basic building + blocks of DAGs and can be done DAG Authors to add missing functionality in their DAGs or by those who write + reusable custom operators for other DAG authors. +* When writing new :doc:`Plugins ` that extend Airflow's functionality beyond + DAG building blocks. Secrets, Timetables, Triggers, Listeners are all examples of such functionality. This + is usually done by users who manage Airflow instances. +* Bundling custom Operators, Hooks, Plugins and releasing them together via + :doc:`provider packages ` - this is usually done by those who intend to + provide reusable set of functionality for external service or application Airflow integrates with. + +All the ways above involve extending or using Airflow Python classes and functions. The classes +and functions mentioned below can be relied to keep backwards-compatible signatures and behaviours within +MAJOR version of Airflow. On the other hand, classes and method started with ``_`` (also known +as protected Python methods) and ``__`` (also known as private Python methods) are not part of the Public +Airflow Interface and might change any time. + +You can also use Airflow's Public Interface via the `Stable REST API `_ (based on the +OpenAPI specification). For specific needs you can also use the +`Airflow Command Line Interface (CLI) `_ though it's behaviour might change +in details (such as output format and available flags) so if you want to rely on those in programmatic +way, the Stable REST API is recommended. + + +Using Public Interface by DAG Authors += + +DAGS + + +The DAG is Airflow's core entity that represents a recurring workflow. You can create a DAG by +instantiating the :class:`~airflow.models.dag.DAG` class in your DAG file. + +Airflow has a set of Example DAGs that you can use to learn how to write DAGs + +.. toctree:: + :includehidden: + :glob: + :maxdepth: 1 + + _api/airflow/example_dags/index + +You can read more about DAGs in :doc:`DAGs `. + +.. _pythonapi:operators: + +Operators +- + +Operators allow for generation of certain types of tasks that become nodes in +the DAG when instantiated. + +There are 3 main types of operators: + +- Operators that performs an **action**, or tell another system to + perform an action +- **Transfer** operators move data from one system to another +- **Sensors** are a certain type of operator that will keep running until a + certain criterion is met. Examples include a specific file landing in HDFS or + S3, a partition appearing in Hive, or a specific time of the day. Sensors + are derived from :class:`~airflow.sensors.base.BaseSensorOperator` and run a poke + method at a specified :attr:`~airflow.sensors.base.BaseSensorOperator.poke_interval` until it + returns ``True``. + +All operators are derived from :class:`~airflow.models.baseoperator.BaseOperator` and acquire much +functionality through inheritance. Since this is the core of the engine, +it's worth taking the time to understand the parameters of :class:`~airflow.models.baseope
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1058843112 ## docs/apache-airflow/administration-and-deployment/public-airflow-interface.rst: ## @@ -0,0 +1,87 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This includes operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +and for automating certain aspects of the Airflow workflow. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +The Public Interface of Airflow consists of a number of different classes and packages that provide access +to the core features and functionality of the system. + +The classes and packages that may be considered as the Public Interface include: + +* The :class:`~airflow.DAG`, which provides a way to define and manage DAGs in Airflow. +* The :class:`~airflow.models.baseoperator.BaseOperator`, which provides a way write custom operators. +* The :class:`~airflow.hooks.base.BaseHook`, which provides a way write custom hooks. +* The :class:`~airflow.models.connection.Connection`, which provides access to external service credentials and configuration. +* The :class:`~airflow.models.variable.Variable`, which provides access to Airflow configuration variables. +* The :class:`~airflow.models.xcom.XCom` which are used to access to inter-task communication data. +* The :class:`~airflow.secrets.BaseSecretsBackend` which are used to define custom secret managers. +* The :class:`~airflow.plugins_manager.AirflowPlugin` which are used to define custom plugins. +* The :class:`~airflow.triggers.base.BaseTrigger`, which are used to implement custom Custom Deferrable Operators (based on ``asyncio``). +* The :class:`~airflow.decorators.base.TaskDecorator`, which provides a way write custom decorators. +* The :class:`~airflow.listeners.listener.ListenerManager` class which provides hooks that can be implemented to respond to DAG/Task lifecycle events. + +.. versionadded:: 2.5 + + Listener public interface has been added in version 2.5. + +* The :class:`~airflow.executors.base_executor.BaseExecutor` - the Executors are the components of Airflow + that are responsible for executing tasks. + +.. versionadded:: 2.6 + + There are a number of different executor implementations built-in Airflow, each with its own unique + characteristics and capabilities. Executor interface was available in earlier version of Airflow but + only as of version 2.6 executors are fully decoupled and Airflow does not rely on built-in set of executors. + You could have implemented (and succeeded) with implementing Executors before Airflow 2.6 and a number + of people succeeded in doing so, but there were some hard-coded behaviours that preferred in-built + executors, and custom executors could not provide full functionality that built-in executors had. + + +What is not part of the Public Interface of Apache Airflow? +=== + +Everything not mentioned in this document should be considered as non-Public Interface. Review Comment: That's a good point. I think K8S is pretty special case because it is both used internally by K8S executor as well as it is exposed externally. And I think there we **could** treat it in a special way and just there make sure that we explicitly decide on which parts of the pod manager or KPO is bound to change.
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1058656390 ## docs/apache-airflow/administration-and-deployment/public-airflow-interface.rst: ## @@ -0,0 +1,87 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This includes operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +and for automating certain aspects of the Airflow workflow. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +The Public Interface of Airflow consists of a number of different classes and packages that provide access +to the core features and functionality of the system. + +The classes and packages that may be considered as the Public Interface include: + +* The :class:`~airflow.DAG`, which provides a way to define and manage DAGs in Airflow. +* The :class:`~airflow.models.baseoperator.BaseOperator`, which provides a way write custom operators. +* The :class:`~airflow.hooks.base.BaseHook`, which provides a way write custom hooks. +* The :class:`~airflow.models.connection.Connection`, which provides access to external service credentials and configuration. +* The :class:`~airflow.models.variable.Variable`, which provides access to Airflow configuration variables. +* The :class:`~airflow.models.xcom.XCom` which are used to access to inter-task communication data. +* The :class:`~airflow.secrets.BaseSecretsBackend` which are used to define custom secret managers. +* The :class:`~airflow.plugins_manager.AirflowPlugin` which are used to define custom plugins. +* The :class:`~airflow.triggers.base.BaseTrigger`, which are used to implement custom Custom Deferrable Operators (based on ``asyncio``). +* The :class:`~airflow.decorators.base.TaskDecorator`, which provides a way write custom decorators. +* The :class:`~airflow.listeners.listener.ListenerManager` class which provides hooks that can be implemented to respond to DAG/Task lifecycle events. + +.. versionadded:: 2.5 + + Listener public interface has been added in version 2.5. + +* The :class:`~airflow.executors.base_executor.BaseExecutor` - the Executors are the components of Airflow + that are responsible for executing tasks. + +.. versionadded:: 2.6 + + There are a number of different executor implementations built-in Airflow, each with its own unique + characteristics and capabilities. Executor interface was available in earlier version of Airflow but + only as of version 2.6 executors are fully decoupled and Airflow does not rely on built-in set of executors. + You could have implemented (and succeeded) with implementing Executors before Airflow 2.6 and a number + of people succeeded in doing so, but there were some hard-coded behaviours that preferred in-built + executors, and custom executors could not provide full functionality that built-in executors had. + + +What is not part of the Public Interface of Apache Airflow? +=== + +Everything not mentioned in this document should be considered as non-Public Interface. Review Comment: BTW. Eventually we might be able to produce airflow typeshed-like package: https://github.com/python/typeshed with only stubs for only "externally public" APIs. This is what should be an "ultimate" goal I think. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1058655785 ## docs/apache-airflow/administration-and-deployment/public-airflow-interface.rst: ## @@ -0,0 +1,87 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This includes operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +and for automating certain aspects of the Airflow workflow. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +The Public Interface of Airflow consists of a number of different classes and packages that provide access +to the core features and functionality of the system. + +The classes and packages that may be considered as the Public Interface include: + +* The :class:`~airflow.DAG`, which provides a way to define and manage DAGs in Airflow. +* The :class:`~airflow.models.baseoperator.BaseOperator`, which provides a way write custom operators. +* The :class:`~airflow.hooks.base.BaseHook`, which provides a way write custom hooks. +* The :class:`~airflow.models.connection.Connection`, which provides access to external service credentials and configuration. +* The :class:`~airflow.models.variable.Variable`, which provides access to Airflow configuration variables. +* The :class:`~airflow.models.xcom.XCom` which are used to access to inter-task communication data. +* The :class:`~airflow.secrets.BaseSecretsBackend` which are used to define custom secret managers. +* The :class:`~airflow.plugins_manager.AirflowPlugin` which are used to define custom plugins. +* The :class:`~airflow.triggers.base.BaseTrigger`, which are used to implement custom Custom Deferrable Operators (based on ``asyncio``). +* The :class:`~airflow.decorators.base.TaskDecorator`, which provides a way write custom decorators. +* The :class:`~airflow.listeners.listener.ListenerManager` class which provides hooks that can be implemented to respond to DAG/Task lifecycle events. + +.. versionadded:: 2.5 + + Listener public interface has been added in version 2.5. + +* The :class:`~airflow.executors.base_executor.BaseExecutor` - the Executors are the components of Airflow + that are responsible for executing tasks. + +.. versionadded:: 2.6 + + There are a number of different executor implementations built-in Airflow, each with its own unique + characteristics and capabilities. Executor interface was available in earlier version of Airflow but + only as of version 2.6 executors are fully decoupled and Airflow does not rely on built-in set of executors. + You could have implemented (and succeeded) with implementing Executors before Airflow 2.6 and a number + of people succeeded in doing so, but there were some hard-coded behaviours that preferred in-built + executors, and custom executors could not provide full functionality that built-in executors had. + + +What is not part of the Public Interface of Apache Airflow? +=== + +Everything not mentioned in this document should be considered as non-Public Interface. Review Comment: > It's also important to clarify that some methods are intentionally "private". E.g. in the operator, it might have helper methods. But these methods are more implementation detail right? If users subclass, though, they may use and depend on these. So what do we do? Ideally, from maintainer perspective, we want the ov
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1058656390 ## docs/apache-airflow/administration-and-deployment/public-airflow-interface.rst: ## @@ -0,0 +1,87 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This includes operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +and for automating certain aspects of the Airflow workflow. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +The Public Interface of Airflow consists of a number of different classes and packages that provide access +to the core features and functionality of the system. + +The classes and packages that may be considered as the Public Interface include: + +* The :class:`~airflow.DAG`, which provides a way to define and manage DAGs in Airflow. +* The :class:`~airflow.models.baseoperator.BaseOperator`, which provides a way write custom operators. +* The :class:`~airflow.hooks.base.BaseHook`, which provides a way write custom hooks. +* The :class:`~airflow.models.connection.Connection`, which provides access to external service credentials and configuration. +* The :class:`~airflow.models.variable.Variable`, which provides access to Airflow configuration variables. +* The :class:`~airflow.models.xcom.XCom` which are used to access to inter-task communication data. +* The :class:`~airflow.secrets.BaseSecretsBackend` which are used to define custom secret managers. +* The :class:`~airflow.plugins_manager.AirflowPlugin` which are used to define custom plugins. +* The :class:`~airflow.triggers.base.BaseTrigger`, which are used to implement custom Custom Deferrable Operators (based on ``asyncio``). +* The :class:`~airflow.decorators.base.TaskDecorator`, which provides a way write custom decorators. +* The :class:`~airflow.listeners.listener.ListenerManager` class which provides hooks that can be implemented to respond to DAG/Task lifecycle events. + +.. versionadded:: 2.5 + + Listener public interface has been added in version 2.5. + +* The :class:`~airflow.executors.base_executor.BaseExecutor` - the Executors are the components of Airflow + that are responsible for executing tasks. + +.. versionadded:: 2.6 + + There are a number of different executor implementations built-in Airflow, each with its own unique + characteristics and capabilities. Executor interface was available in earlier version of Airflow but + only as of version 2.6 executors are fully decoupled and Airflow does not rely on built-in set of executors. + You could have implemented (and succeeded) with implementing Executors before Airflow 2.6 and a number + of people succeeded in doing so, but there were some hard-coded behaviours that preferred in-built + executors, and custom executors could not provide full functionality that built-in executors had. + + +What is not part of the Public Interface of Apache Airflow? +=== + +Everything not mentioned in this document should be considered as non-Public Interface. Review Comment: BTW. Eventually we might be able to produce airflow typeshed https://github.com/python/typeshed with only stubs for only "externally public" APIs. This is what should be an "ultimate" goal I think. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and us
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1058655785 ## docs/apache-airflow/administration-and-deployment/public-airflow-interface.rst: ## @@ -0,0 +1,87 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This includes operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +and for automating certain aspects of the Airflow workflow. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +The Public Interface of Airflow consists of a number of different classes and packages that provide access +to the core features and functionality of the system. + +The classes and packages that may be considered as the Public Interface include: + +* The :class:`~airflow.DAG`, which provides a way to define and manage DAGs in Airflow. +* The :class:`~airflow.models.baseoperator.BaseOperator`, which provides a way write custom operators. +* The :class:`~airflow.hooks.base.BaseHook`, which provides a way write custom hooks. +* The :class:`~airflow.models.connection.Connection`, which provides access to external service credentials and configuration. +* The :class:`~airflow.models.variable.Variable`, which provides access to Airflow configuration variables. +* The :class:`~airflow.models.xcom.XCom` which are used to access to inter-task communication data. +* The :class:`~airflow.secrets.BaseSecretsBackend` which are used to define custom secret managers. +* The :class:`~airflow.plugins_manager.AirflowPlugin` which are used to define custom plugins. +* The :class:`~airflow.triggers.base.BaseTrigger`, which are used to implement custom Custom Deferrable Operators (based on ``asyncio``). +* The :class:`~airflow.decorators.base.TaskDecorator`, which provides a way write custom decorators. +* The :class:`~airflow.listeners.listener.ListenerManager` class which provides hooks that can be implemented to respond to DAG/Task lifecycle events. + +.. versionadded:: 2.5 + + Listener public interface has been added in version 2.5. + +* The :class:`~airflow.executors.base_executor.BaseExecutor` - the Executors are the components of Airflow + that are responsible for executing tasks. + +.. versionadded:: 2.6 + + There are a number of different executor implementations built-in Airflow, each with its own unique + characteristics and capabilities. Executor interface was available in earlier version of Airflow but + only as of version 2.6 executors are fully decoupled and Airflow does not rely on built-in set of executors. + You could have implemented (and succeeded) with implementing Executors before Airflow 2.6 and a number + of people succeeded in doing so, but there were some hard-coded behaviours that preferred in-built + executors, and custom executors could not provide full functionality that built-in executors had. + + +What is not part of the Public Interface of Apache Airflow? +=== + +Everything not mentioned in this document should be considered as non-Public Interface. Review Comment: > It's also important to clarify that some methods are intentionally "private". E.g. in the operator, it might have helper methods. But these methods are more implementation detail right? If users subclass, though, they may use and depend on these. So what do we do? Ideally, from maintainer perspective, we want the ov
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1058655785 ## docs/apache-airflow/administration-and-deployment/public-airflow-interface.rst: ## @@ -0,0 +1,87 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This includes operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +and for automating certain aspects of the Airflow workflow. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +The Public Interface of Airflow consists of a number of different classes and packages that provide access +to the core features and functionality of the system. + +The classes and packages that may be considered as the Public Interface include: + +* The :class:`~airflow.DAG`, which provides a way to define and manage DAGs in Airflow. +* The :class:`~airflow.models.baseoperator.BaseOperator`, which provides a way write custom operators. +* The :class:`~airflow.hooks.base.BaseHook`, which provides a way write custom hooks. +* The :class:`~airflow.models.connection.Connection`, which provides access to external service credentials and configuration. +* The :class:`~airflow.models.variable.Variable`, which provides access to Airflow configuration variables. +* The :class:`~airflow.models.xcom.XCom` which are used to access to inter-task communication data. +* The :class:`~airflow.secrets.BaseSecretsBackend` which are used to define custom secret managers. +* The :class:`~airflow.plugins_manager.AirflowPlugin` which are used to define custom plugins. +* The :class:`~airflow.triggers.base.BaseTrigger`, which are used to implement custom Custom Deferrable Operators (based on ``asyncio``). +* The :class:`~airflow.decorators.base.TaskDecorator`, which provides a way write custom decorators. +* The :class:`~airflow.listeners.listener.ListenerManager` class which provides hooks that can be implemented to respond to DAG/Task lifecycle events. + +.. versionadded:: 2.5 + + Listener public interface has been added in version 2.5. + +* The :class:`~airflow.executors.base_executor.BaseExecutor` - the Executors are the components of Airflow + that are responsible for executing tasks. + +.. versionadded:: 2.6 + + There are a number of different executor implementations built-in Airflow, each with its own unique + characteristics and capabilities. Executor interface was available in earlier version of Airflow but + only as of version 2.6 executors are fully decoupled and Airflow does not rely on built-in set of executors. + You could have implemented (and succeeded) with implementing Executors before Airflow 2.6 and a number + of people succeeded in doing so, but there were some hard-coded behaviours that preferred in-built + executors, and custom executors could not provide full functionality that built-in executors had. + + +What is not part of the Public Interface of Apache Airflow? +=== + +Everything not mentioned in this document should be considered as non-Public Interface. Review Comment: > It's also important to clarify that some methods are intentionally "private". E.g. in the operator, it might have helper methods. But these methods are more implementation detail right? If users subclass, though, they may use and depend on these. So what do we do? Ideally, from maintainer perspective, we want the ov
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1058648489 ## docs/apache-airflow/administration-and-deployment/public-airflow-interface.rst: ## @@ -0,0 +1,87 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This includes operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +and for automating certain aspects of the Airflow workflow. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +The Public Interface of Airflow consists of a number of different classes and packages that provide access +to the core features and functionality of the system. + +The classes and packages that may be considered as the Public Interface include: + +* The :class:`~airflow.DAG`, which provides a way to define and manage DAGs in Airflow. +* The :class:`~airflow.models.baseoperator.BaseOperator`, which provides a way write custom operators. +* The :class:`~airflow.hooks.base.BaseHook`, which provides a way write custom hooks. +* The :class:`~airflow.models.connection.Connection`, which provides access to external service credentials and configuration. +* The :class:`~airflow.models.variable.Variable`, which provides access to Airflow configuration variables. +* The :class:`~airflow.models.xcom.XCom` which are used to access to inter-task communication data. +* The :class:`~airflow.secrets.BaseSecretsBackend` which are used to define custom secret managers. +* The :class:`~airflow.plugins_manager.AirflowPlugin` which are used to define custom plugins. +* The :class:`~airflow.triggers.base.BaseTrigger`, which are used to implement custom Custom Deferrable Operators (based on ``asyncio``). +* The :class:`~airflow.decorators.base.TaskDecorator`, which provides a way write custom decorators. +* The :class:`~airflow.listeners.listener.ListenerManager` class which provides hooks that can be implemented to respond to DAG/Task lifecycle events. + +.. versionadded:: 2.5 + + Listener public interface has been added in version 2.5. + +* The :class:`~airflow.executors.base_executor.BaseExecutor` - the Executors are the components of Airflow + that are responsible for executing tasks. + +.. versionadded:: 2.6 + + There are a number of different executor implementations built-in Airflow, each with its own unique + characteristics and capabilities. Executor interface was available in earlier version of Airflow but + only as of version 2.6 executors are fully decoupled and Airflow does not rely on built-in set of executors. + You could have implemented (and succeeded) with implementing Executors before Airflow 2.6 and a number + of people succeeded in doing so, but there were some hard-coded behaviours that preferred in-built + executors, and custom executors could not provide full functionality that built-in executors had. + + +What is not part of the Public Interface of Apache Airflow? +=== + +Everything not mentioned in this document should be considered as non-Public Interface. Review Comment: Maybe this is misunderstanding - what I wrote above was not about what provider packages "provides" - but what they "consume". This document indeed does not specify anything about what providers provide - it's only what Airflow "produces" and providers "consume" as users of that. The Community Providers have t
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1058628066 ## docs/apache-airflow/administration-and-deployment/public-airflow-interface.rst: ## @@ -0,0 +1,87 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This includes operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +and for automating certain aspects of the Airflow workflow. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +The Public Interface of Airflow consists of a number of different classes and packages that provide access +to the core features and functionality of the system. + +The classes and packages that may be considered as the Public Interface include: + +* The :class:`~airflow.DAG`, which provides a way to define and manage DAGs in Airflow. +* The :class:`~airflow.models.baseoperator.BaseOperator`, which provides a way write custom operators. +* The :class:`~airflow.hooks.base.BaseHook`, which provides a way write custom hooks. +* The :class:`~airflow.models.connection.Connection`, which provides access to external service credentials and configuration. +* The :class:`~airflow.models.variable.Variable`, which provides access to Airflow configuration variables. +* The :class:`~airflow.models.xcom.XCom` which are used to access to inter-task communication data. +* The :class:`~airflow.secrets.BaseSecretsBackend` which are used to define custom secret managers. +* The :class:`~airflow.plugins_manager.AirflowPlugin` which are used to define custom plugins. +* The :class:`~airflow.triggers.base.BaseTrigger`, which are used to implement custom Custom Deferrable Operators (based on ``asyncio``). +* The :class:`~airflow.decorators.base.TaskDecorator`, which provides a way write custom decorators. +* The :class:`~airflow.listeners.listener.ListenerManager` class which provides hooks that can be implemented to respond to DAG/Task lifecycle events. + +.. versionadded:: 2.5 + + Listener public interface has been added in version 2.5. + +* The :class:`~airflow.executors.base_executor.BaseExecutor` - the Executors are the components of Airflow + that are responsible for executing tasks. + +.. versionadded:: 2.6 + + There are a number of different executor implementations built-in Airflow, each with its own unique + characteristics and capabilities. Executor interface was available in earlier version of Airflow but + only as of version 2.6 executors are fully decoupled and Airflow does not rely on built-in set of executors. + You could have implemented (and succeeded) with implementing Executors before Airflow 2.6 and a number + of people succeeded in doing so, but there were some hard-coded behaviours that preferred in-built + executors, and custom executors could not provide full functionality that built-in executors had. + + +What is not part of the Public Interface of Apache Airflow? +=== + +Everything not mentioned in this document should be considered as non-Public Interface. Review Comment: And yes I want to add eventually tests to make sure that all our providers are only using what we consider public" and nothing else. This will be partially done as part of AIP-44 (for DB methods) but it can be extended to all Python calls made by the providers. -- This is an automated message from the Apache Git S
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1058627698 ## docs/apache-airflow/administration-and-deployment/public-airflow-interface.rst: ## @@ -0,0 +1,87 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This includes operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +and for automating certain aspects of the Airflow workflow. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +The Public Interface of Airflow consists of a number of different classes and packages that provide access +to the core features and functionality of the system. + +The classes and packages that may be considered as the Public Interface include: + +* The :class:`~airflow.DAG`, which provides a way to define and manage DAGs in Airflow. +* The :class:`~airflow.models.baseoperator.BaseOperator`, which provides a way write custom operators. +* The :class:`~airflow.hooks.base.BaseHook`, which provides a way write custom hooks. +* The :class:`~airflow.models.connection.Connection`, which provides access to external service credentials and configuration. +* The :class:`~airflow.models.variable.Variable`, which provides access to Airflow configuration variables. +* The :class:`~airflow.models.xcom.XCom` which are used to access to inter-task communication data. +* The :class:`~airflow.secrets.BaseSecretsBackend` which are used to define custom secret managers. +* The :class:`~airflow.plugins_manager.AirflowPlugin` which are used to define custom plugins. +* The :class:`~airflow.triggers.base.BaseTrigger`, which are used to implement custom Custom Deferrable Operators (based on ``asyncio``). +* The :class:`~airflow.decorators.base.TaskDecorator`, which provides a way write custom decorators. +* The :class:`~airflow.listeners.listener.ListenerManager` class which provides hooks that can be implemented to respond to DAG/Task lifecycle events. + +.. versionadded:: 2.5 + + Listener public interface has been added in version 2.5. + +* The :class:`~airflow.executors.base_executor.BaseExecutor` - the Executors are the components of Airflow + that are responsible for executing tasks. + +.. versionadded:: 2.6 + + There are a number of different executor implementations built-in Airflow, each with its own unique + characteristics and capabilities. Executor interface was available in earlier version of Airflow but + only as of version 2.6 executors are fully decoupled and Airflow does not rely on built-in set of executors. + You could have implemented (and succeeded) with implementing Executors before Airflow 2.6 and a number + of people succeeded in doing so, but there were some hard-coded behaviours that preferred in-built + executors, and custom executors could not provide full functionality that built-in executors had. + + +What is not part of the Public Interface of Apache Airflow? +=== + +Everything not mentioned in this document should be considered as non-Public Interface. Review Comment: And the list does not **have** to be complete now. If we forget something before merging it - we can always add it later - there is completely no harm in that. It will be "eventually complete" if we follow it for quite some time and decide that some things should be "publicised". -- This is an automated message fro
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1058627308 ## docs/apache-airflow/administration-and-deployment/public-airflow-interface.rst: ## @@ -0,0 +1,87 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This includes operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +and for automating certain aspects of the Airflow workflow. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +The Public Interface of Airflow consists of a number of different classes and packages that provide access +to the core features and functionality of the system. + +The classes and packages that may be considered as the Public Interface include: + +* The :class:`~airflow.DAG`, which provides a way to define and manage DAGs in Airflow. +* The :class:`~airflow.models.baseoperator.BaseOperator`, which provides a way write custom operators. +* The :class:`~airflow.hooks.base.BaseHook`, which provides a way write custom hooks. +* The :class:`~airflow.models.connection.Connection`, which provides access to external service credentials and configuration. +* The :class:`~airflow.models.variable.Variable`, which provides access to Airflow configuration variables. +* The :class:`~airflow.models.xcom.XCom` which are used to access to inter-task communication data. +* The :class:`~airflow.secrets.BaseSecretsBackend` which are used to define custom secret managers. +* The :class:`~airflow.plugins_manager.AirflowPlugin` which are used to define custom plugins. +* The :class:`~airflow.triggers.base.BaseTrigger`, which are used to implement custom Custom Deferrable Operators (based on ``asyncio``). +* The :class:`~airflow.decorators.base.TaskDecorator`, which provides a way write custom decorators. +* The :class:`~airflow.listeners.listener.ListenerManager` class which provides hooks that can be implemented to respond to DAG/Task lifecycle events. + +.. versionadded:: 2.5 + + Listener public interface has been added in version 2.5. + +* The :class:`~airflow.executors.base_executor.BaseExecutor` - the Executors are the components of Airflow + that are responsible for executing tasks. + +.. versionadded:: 2.6 + + There are a number of different executor implementations built-in Airflow, each with its own unique + characteristics and capabilities. Executor interface was available in earlier version of Airflow but + only as of version 2.6 executors are fully decoupled and Airflow does not rely on built-in set of executors. + You could have implemented (and succeeded) with implementing Executors before Airflow 2.6 and a number + of people succeeded in doing so, but there were some hard-coded behaviours that preferred in-built + executors, and custom executors could not provide full functionality that built-in executors had. + + +What is not part of the Public Interface of Apache Airflow? +=== + +Everything not mentioned in this document should be considered as non-Public Interface. Review Comment: IMHO - it should also address providers (and especially them). Rather than adding private tags, I think we should allowlist everything that should be public here. If we forgot something we should add. All the rest should be private by definition IMHO. This is the whole purpose of this list. And we should expl
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1051383543 ## docs/apache-airflow/administration-and-deployment/public-airflow-interface.rst: ## @@ -0,0 +1,118 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This can include operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +as well as for automating certain aspects of the Airflow workflow. + +In general, the Public Interface is an important part of the Airflow ecosystem and can be a powerful +tool for users and developers who want to extend the functionality of the system. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +Apache Airflow has a number of different Public Interfaces that allow developers to interact with various +aspects of the system. Some examples of the types of Public Interfaces exposed as Python objects +that are available in Apache Airflow include: + +* `DAG `_ (Directed Acyclic Graph) APIs, which allow developers to create, manage, + and access DAGs in Airflow. +* `Task `_ APIs, which provide access to information about individual tasks within + a DAG, such as their dependencies and execution status. +* `Operator `_ APIs, which allows the developers to write their custom Operators. +* `Decorators `_ APIs, which allows the developers to write their + custom decorators to make it easier to write `TaskFlow `_ DAGs. +* `Secret Managers `_ APIs, which allows the developers to write their custom + Secret Managers to safely access credentials and other secret configuration of their workflows. +* `Connection management `_ APIs, which allow developers to manage + connections to external systems. +* `XCom `_, which allow developers to manage cross-task communication within Airflow. +* `Variables `_, which allow developers to manage variables within Airflow. +* `Executors `_, which allow developers to manage the execution of tasks within Airflow. +* `Listeners `_, which allow developers to react to DAG/Task lifecycle events. +* `Plugins `_, which allow developers to extend internal Airflow capabilities - add new UI + pages, custom `TimeTables `_, `Extra Links `_, + `Triggers `_, and `Listeners `_. + +What is not part of the Public Interface of Apache Airflow? +=== + +Everything not mentioned in this document should be considered as non-Public Interface. + +The users however, might have some assumptions about different parts of Airflow, thinking that +they can rely on them, so here we try to clarify and want to be explicit that they are not part of the +Public Interface: + +* `Database structure `_ is considered to be an internal implementation + detail and you should not assume the structure is going to be maintained in + backwards-compatible way. + +* `Web UI `_ is considered to be continuously adapting and evolving for Apache Airflow and + you should not assume that the UI will remain as it is in backwards-compatible way. Views and screens + might be updated and removed in major releases without impacting backwards-compatibility. + +* `Python API `_ (except the explicitly mentioned classes below), are considered an + internal implementation details and you should not assume they will be maintained + in backwards-compatible way. + +Which classes and packages are part of the Public Interface of Apache Airflo
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1051383543 ## docs/apache-airflow/administration-and-deployment/public-airflow-interface.rst: ## @@ -0,0 +1,118 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This can include operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +as well as for automating certain aspects of the Airflow workflow. + +In general, the Public Interface is an important part of the Airflow ecosystem and can be a powerful +tool for users and developers who want to extend the functionality of the system. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +Apache Airflow has a number of different Public Interfaces that allow developers to interact with various +aspects of the system. Some examples of the types of Public Interfaces exposed as Python objects +that are available in Apache Airflow include: + +* `DAG `_ (Directed Acyclic Graph) APIs, which allow developers to create, manage, + and access DAGs in Airflow. +* `Task `_ APIs, which provide access to information about individual tasks within + a DAG, such as their dependencies and execution status. +* `Operator `_ APIs, which allows the developers to write their custom Operators. +* `Decorators `_ APIs, which allows the developers to write their + custom decorators to make it easier to write `TaskFlow `_ DAGs. +* `Secret Managers `_ APIs, which allows the developers to write their custom + Secret Managers to safely access credentials and other secret configuration of their workflows. +* `Connection management `_ APIs, which allow developers to manage + connections to external systems. +* `XCom `_, which allow developers to manage cross-task communication within Airflow. +* `Variables `_, which allow developers to manage variables within Airflow. +* `Executors `_, which allow developers to manage the execution of tasks within Airflow. +* `Listeners `_, which allow developers to react to DAG/Task lifecycle events. +* `Plugins `_, which allow developers to extend internal Airflow capabilities - add new UI + pages, custom `TimeTables `_, `Extra Links `_, + `Triggers `_, and `Listeners `_. + +What is not part of the Public Interface of Apache Airflow? +=== + +Everything not mentioned in this document should be considered as non-Public Interface. + +The users however, might have some assumptions about different parts of Airflow, thinking that +they can rely on them, so here we try to clarify and want to be explicit that they are not part of the +Public Interface: + +* `Database structure `_ is considered to be an internal implementation + detail and you should not assume the structure is going to be maintained in + backwards-compatible way. + +* `Web UI `_ is considered to be continuously adapting and evolving for Apache Airflow and + you should not assume that the UI will remain as it is in backwards-compatible way. Views and screens + might be updated and removed in major releases without impacting backwards-compatibility. + +* `Python API `_ (except the explicitly mentioned classes below), are considered an + internal implementation details and you should not assume they will be maintained + in backwards-compatible way. + +Which classes and packages are part of the Public Interface of Apache Airflo
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1051383399 ## docs/apache-airflow/administration-and-deployment/public-airflow-interface.rst: ## @@ -0,0 +1,118 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This can include operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +as well as for automating certain aspects of the Airflow workflow. + +In general, the Public Interface is an important part of the Airflow ecosystem and can be a powerful +tool for users and developers who want to extend the functionality of the system. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +Apache Airflow has a number of different Public Interfaces that allow developers to interact with various +aspects of the system. Some examples of the types of Public Interfaces exposed as Python objects +that are available in Apache Airflow include: + +* `DAG `_ (Directed Acyclic Graph) APIs, which allow developers to create, manage, + and access DAGs in Airflow. +* `Task `_ APIs, which provide access to information about individual tasks within + a DAG, such as their dependencies and execution status. +* `Operator `_ APIs, which allows the developers to write their custom Operators. +* `Decorators `_ APIs, which allows the developers to write their + custom decorators to make it easier to write `TaskFlow `_ DAGs. +* `Secret Managers `_ APIs, which allows the developers to write their custom + Secret Managers to safely access credentials and other secret configuration of their workflows. +* `Connection management `_ APIs, which allow developers to manage + connections to external systems. +* `XCom `_, which allow developers to manage cross-task communication within Airflow. +* `Variables `_, which allow developers to manage variables within Airflow. +* `Executors `_, which allow developers to manage the execution of tasks within Airflow. +* `Listeners `_, which allow developers to react to DAG/Task lifecycle events. +* `Plugins `_, which allow developers to extend internal Airflow capabilities - add new UI + pages, custom `TimeTables `_, `Extra Links `_, + `Triggers `_, and `Listeners `_. + +What is not part of the Public Interface of Apache Airflow? +=== + +Everything not mentioned in this document should be considered as non-Public Interface. + +The users however, might have some assumptions about different parts of Airflow, thinking that +they can rely on them, so here we try to clarify and want to be explicit that they are not part of the +Public Interface: Review Comment: I think it could be answered as response to my previous explanation which I gave above. So let me repeat again - that if we list those explicitly without context and telling why we are listing those (because we've learned from the past that our users tend to think they can treat those compoents as "public interface". And listing them here explicitly is the way to avoid any discussions. I rephrased and shortened it to better reflect what I mean. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@airflow.apache.org For queries about this service, please cont
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1051382595 ## docs/apache-airflow/administration-and-deployment/public-airflow-interface.rst: ## @@ -0,0 +1,118 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This can include operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +as well as for automating certain aspects of the Airflow workflow. + +In general, the Public Interface is an important part of the Airflow ecosystem and can be a powerful +tool for users and developers who want to extend the functionality of the system. Review Comment: Yes. Almost last remnant of the GPTChat. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@airflow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1051382483 ## docs/apache-airflow/administration-and-deployment/public-airflow-interface.rst: ## @@ -0,0 +1,118 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This can include operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +as well as for automating certain aspects of the Airflow workflow. + +In general, the Public Interface is an important part of the Airflow ecosystem and can be a powerful +tool for users and developers who want to extend the functionality of the system. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +Apache Airflow has a number of different Public Interfaces that allow developers to interact with various +aspects of the system. Some examples of the types of Public Interfaces exposed as Python objects +that are available in Apache Airflow include: Review Comment: This whole section went away with consolidating the two packages. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@airflow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1051380916 ## docs/apache-airflow/administration-and-deployment/public-airflow-interface.rst: ## @@ -0,0 +1,118 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This can include operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +as well as for automating certain aspects of the Airflow workflow. + +In general, the Public Interface is an important part of the Airflow ecosystem and can be a powerful +tool for users and developers who want to extend the functionality of the system. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +Apache Airflow has a number of different Public Interfaces that allow developers to interact with various +aspects of the system. Some examples of the types of Public Interfaces exposed as Python objects +that are available in Apache Airflow include: + +* `DAG `_ (Directed Acyclic Graph) APIs, which allow developers to create, manage, + and access DAGs in Airflow. +* `Task `_ APIs, which provide access to information about individual tasks within + a DAG, such as their dependencies and execution status. +* `Operator `_ APIs, which allows the developers to write their custom Operators. +* `Decorators `_ APIs, which allows the developers to write their + custom decorators to make it easier to write `TaskFlow `_ DAGs. +* `Secret Managers `_ APIs, which allows the developers to write their custom + Secret Managers to safely access credentials and other secret configuration of their workflows. +* `Connection management `_ APIs, which allow developers to manage + connections to external systems. +* `XCom `_, which allow developers to manage cross-task communication within Airflow. +* `Variables `_, which allow developers to manage variables within Airflow. +* `Executors `_, which allow developers to manage the execution of tasks within Airflow. +* `Listeners `_, which allow developers to react to DAG/Task lifecycle events. +* `Plugins `_, which allow developers to extend internal Airflow capabilities - add new UI + pages, custom `TimeTables `_, `Extra Links `_, + `Triggers `_, and `Listeners `_. Review Comment: Yes. It was orginally higher level but it evolved into nearly the same over time. I will consolidate. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@airflow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1050150795 ## docs/apache-airflow/public-airflow-interface.rst: ## @@ -0,0 +1,115 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This can include operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +as well as for automating certain aspects of the Airflow workflow. + +In general, the Public Interface is an important part of the Airflow ecosystem and can be a powerful +tool for users and developers who want to extend the functionality of the system. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +Apache Airflow has a number of different Public Interfaces that allow developers to interact with various +aspects of the system. Some examples of the types of Public Interfaces exposed as Python objects +that are available in Apache Airflow include: + +* `DAG `_ (Directed Acyclic Graph) APIs, which allow developers to create, manage, + and access DAGs in Airflow. +* `Task `_ APIs, which provide access to information about individual tasks within + a DAG, such as their dependencies and execution status. +* `Operator `_ APIs, which allows the developers to write their custom Operators. +* `Decorators `_ APIs, which allows the developers to write their + custom decorators to make it easier to write `TaskFlow `_ DAGs. +* `Secret Managers `_ APIs, which allows the developers to write their custom + Secret Managers to safely access credentials and other secret configuration of their workflows. +* `Connection management `_ APIs, which allow developers to manage + connections to external systems +* `XCom `_, which allow developers to manage cross-task communication within Airflow. +* `Variables `_, which allow developers to manage variables within Airflow. +* `Executors `_, which allow developers to manage the execution of tasks within Airflow. +* `Listeners `_, which allow developers to react to DAG/Task lifecycle events. +* `Plugins `_, which allow developers to extend internal Airflow capabilities - add new UI + pages, custom `TimeTables `_, `Extra Links `_, + `Triggers `_. `Listeners `_. + +What is not part of the Public Interface of Apache Airflow? +=== + +Everything not mentioned in this document should be considered as non-Public Interface. + +The users however, might have some assumptions about different parts of Airflow, thinking that +they can rely on them, so here we try to clarify and want to be explicit that they are not part of the +Public Interface: + +* `Database structure `_ is considered to be an internal implementation + detail and you should not assume the structure is going to be maintained in + backwards-compatible way. + +* `Web UI `_ is considered to be continuously adapting and evolving for Apache Airflow and + you should not assume that the UI will remain as it is in backwards-compatible way. Views and screens + might be updated and removed in major releases without impacting backwards-compatibility. + +* `Python API `_ (except the explicitly mentioned classes below), are considered an + internal implementation details and you should not assume they will be maintained + in backwards-compatible way. + +Which classes and packages are part of the Public Interface of Apache Airflow? +===
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1050166158 ## docs/apache-airflow/public-airflow-interface.rst: ## @@ -0,0 +1,115 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This can include operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +as well as for automating certain aspects of the Airflow workflow. + +In general, the Public Interface is an important part of the Airflow ecosystem and can be a powerful +tool for users and developers who want to extend the functionality of the system. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +Apache Airflow has a number of different Public Interfaces that allow developers to interact with various +aspects of the system. Some examples of the types of Public Interfaces exposed as Python objects +that are available in Apache Airflow include: + +* `DAG `_ (Directed Acyclic Graph) APIs, which allow developers to create, manage, + and access DAGs in Airflow. +* `Task `_ APIs, which provide access to information about individual tasks within + a DAG, such as their dependencies and execution status. +* `Operator `_ APIs, which allows the developers to write their custom Operators. +* `Decorators `_ APIs, which allows the developers to write their + custom decorators to make it easier to write `TaskFlow `_ DAGs. +* `Secret Managers `_ APIs, which allows the developers to write their custom + Secret Managers to safely access credentials and other secret configuration of their workflows. +* `Connection management `_ APIs, which allow developers to manage + connections to external systems +* `XCom `_, which allow developers to manage cross-task communication within Airflow. +* `Variables `_, which allow developers to manage variables within Airflow. +* `Executors `_, which allow developers to manage the execution of tasks within Airflow. +* `Listeners `_, which allow developers to react to DAG/Task lifecycle events. +* `Plugins `_, which allow developers to extend internal Airflow capabilities - add new UI + pages, custom `TimeTables `_, `Extra Links `_, + `Triggers `_. `Listeners `_. + +What is not part of the Public Interface of Apache Airflow? +=== + +Everything not mentioned in this document should be considered as non-Public Interface. + +The users however, might have some assumptions about different parts of Airflow, thinking that +they can rely on them, so here we try to clarify and want to be explicit that they are not part of the +Public Interface: + +* `Database structure `_ is considered to be an internal implementation + detail and you should not assume the structure is going to be maintained in + backwards-compatible way. + +* `Web UI `_ is considered to be continuously adapting and evolving for Apache Airflow and + you should not assume that the UI will remain as it is in backwards-compatible way. Views and screens + might be updated and removed in major releases without impacting backwards-compatibility. + +* `Python API `_ (except the explicitly mentioned classes below), are considered an + internal implementation details and you should not assume they will be maintained + in backwards-compatible way. + +Which classes and packages are part of the Public Interface of Apache Airflow? +===
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1050166158 ## docs/apache-airflow/public-airflow-interface.rst: ## @@ -0,0 +1,115 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This can include operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +as well as for automating certain aspects of the Airflow workflow. + +In general, the Public Interface is an important part of the Airflow ecosystem and can be a powerful +tool for users and developers who want to extend the functionality of the system. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +Apache Airflow has a number of different Public Interfaces that allow developers to interact with various +aspects of the system. Some examples of the types of Public Interfaces exposed as Python objects +that are available in Apache Airflow include: + +* `DAG `_ (Directed Acyclic Graph) APIs, which allow developers to create, manage, + and access DAGs in Airflow. +* `Task `_ APIs, which provide access to information about individual tasks within + a DAG, such as their dependencies and execution status. +* `Operator `_ APIs, which allows the developers to write their custom Operators. +* `Decorators `_ APIs, which allows the developers to write their + custom decorators to make it easier to write `TaskFlow `_ DAGs. +* `Secret Managers `_ APIs, which allows the developers to write their custom + Secret Managers to safely access credentials and other secret configuration of their workflows. +* `Connection management `_ APIs, which allow developers to manage + connections to external systems +* `XCom `_, which allow developers to manage cross-task communication within Airflow. +* `Variables `_, which allow developers to manage variables within Airflow. +* `Executors `_, which allow developers to manage the execution of tasks within Airflow. +* `Listeners `_, which allow developers to react to DAG/Task lifecycle events. +* `Plugins `_, which allow developers to extend internal Airflow capabilities - add new UI + pages, custom `TimeTables `_, `Extra Links `_, + `Triggers `_. `Listeners `_. + +What is not part of the Public Interface of Apache Airflow? +=== + +Everything not mentioned in this document should be considered as non-Public Interface. + +The users however, might have some assumptions about different parts of Airflow, thinking that +they can rely on them, so here we try to clarify and want to be explicit that they are not part of the +Public Interface: + +* `Database structure `_ is considered to be an internal implementation + detail and you should not assume the structure is going to be maintained in + backwards-compatible way. + +* `Web UI `_ is considered to be continuously adapting and evolving for Apache Airflow and + you should not assume that the UI will remain as it is in backwards-compatible way. Views and screens + might be updated and removed in major releases without impacting backwards-compatibility. + +* `Python API `_ (except the explicitly mentioned classes below), are considered an + internal implementation details and you should not assume they will be maintained + in backwards-compatible way. + +Which classes and packages are part of the Public Interface of Apache Airflow? +===
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1050144300 ## docs/apache-airflow/public-airflow-interface.rst: ## @@ -0,0 +1,115 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This can include operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +as well as for automating certain aspects of the Airflow workflow. + +In general, the Public Interface is an important part of the Airflow ecosystem and can be a powerful +tool for users and developers who want to extend the functionality of the system. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +Apache Airflow has a number of different Public Interfaces that allow developers to interact with various +aspects of the system. Some examples of the types of Public Interfaces exposed as Python objects +that are available in Apache Airflow include: + +* `DAG `_ (Directed Acyclic Graph) APIs, which allow developers to create, manage, + and access DAGs in Airflow. +* `Task `_ APIs, which provide access to information about individual tasks within + a DAG, such as their dependencies and execution status. +* `Operator `_ APIs, which allows the developers to write their custom Operators. +* `Decorators `_ APIs, which allows the developers to write their + custom decorators to make it easier to write `TaskFlow `_ DAGs. +* `Secret Managers `_ APIs, which allows the developers to write their custom + Secret Managers to safely access credentials and other secret configuration of their workflows. +* `Connection management `_ APIs, which allow developers to manage + connections to external systems +* `XCom `_, which allow developers to manage cross-task communication within Airflow. +* `Variables `_, which allow developers to manage variables within Airflow. +* `Executors `_, which allow developers to manage the execution of tasks within Airflow. +* `Listeners `_, which allow developers to react to DAG/Task lifecycle events. +* `Plugins `_, which allow developers to extend internal Airflow capabilities - add new UI + pages, custom `TimeTables `_, `Extra Links `_, + `Triggers `_. `Listeners `_. + +What is not part of the Public Interface of Apache Airflow? +=== + +Everything not mentioned in this document should be considered as non-Public Interface. + +The users however, might have some assumptions about different parts of Airflow, thinking that +they can rely on them, so here we try to clarify and want to be explicit that they are not part of the +Public Interface: + +* `Database structure `_ is considered to be an internal implementation + detail and you should not assume the structure is going to be maintained in + backwards-compatible way. + +* `Web UI `_ is considered to be continuously adapting and evolving for Apache Airflow and + you should not assume that the UI will remain as it is in backwards-compatible way. Views and screens + might be updated and removed in major releases without impacting backwards-compatibility. + +* `Python API `_ (except the explicitly mentioned classes below), are considered an + internal implementation details and you should not assume they will be maintained + in backwards-compatible way. + +Which classes and packages are part of the Public Interface of Apache Airflow? +===
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1050151517 ## docs/apache-airflow/public-airflow-interface.rst: ## @@ -0,0 +1,115 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This can include operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +as well as for automating certain aspects of the Airflow workflow. + +In general, the Public Interface is an important part of the Airflow ecosystem and can be a powerful +tool for users and developers who want to extend the functionality of the system. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +Apache Airflow has a number of different Public Interfaces that allow developers to interact with various +aspects of the system. Some examples of the types of Public Interfaces exposed as Python objects +that are available in Apache Airflow include: + +* `DAG `_ (Directed Acyclic Graph) APIs, which allow developers to create, manage, + and access DAGs in Airflow. +* `Task `_ APIs, which provide access to information about individual tasks within + a DAG, such as their dependencies and execution status. +* `Operator `_ APIs, which allows the developers to write their custom Operators. +* `Decorators `_ APIs, which allows the developers to write their + custom decorators to make it easier to write `TaskFlow `_ DAGs. +* `Secret Managers `_ APIs, which allows the developers to write their custom + Secret Managers to safely access credentials and other secret configuration of their workflows. +* `Connection management `_ APIs, which allow developers to manage + connections to external systems +* `XCom `_, which allow developers to manage cross-task communication within Airflow. +* `Variables `_, which allow developers to manage variables within Airflow. +* `Executors `_, which allow developers to manage the execution of tasks within Airflow. +* `Listeners `_, which allow developers to react to DAG/Task lifecycle events. +* `Plugins `_, which allow developers to extend internal Airflow capabilities - add new UI + pages, custom `TimeTables `_, `Extra Links `_, + `Triggers `_. `Listeners `_. + +What is not part of the Public Interface of Apache Airflow? +=== + +Everything not mentioned in this document should be considered as non-Public Interface. + +The users however, might have some assumptions about different parts of Airflow, thinking that +they can rely on them, so here we try to clarify and want to be explicit that they are not part of the +Public Interface: + +* `Database structure `_ is considered to be an internal implementation + detail and you should not assume the structure is going to be maintained in + backwards-compatible way. + +* `Web UI `_ is considered to be continuously adapting and evolving for Apache Airflow and + you should not assume that the UI will remain as it is in backwards-compatible way. Views and screens + might be updated and removed in major releases without impacting backwards-compatibility. + +* `Python API `_ (except the explicitly mentioned classes below), are considered an + internal implementation details and you should not assume they will be maintained + in backwards-compatible way. + +Which classes and packages are part of the Public Interface of Apache Airflow? +===
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1050150795 ## docs/apache-airflow/public-airflow-interface.rst: ## @@ -0,0 +1,115 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This can include operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +as well as for automating certain aspects of the Airflow workflow. + +In general, the Public Interface is an important part of the Airflow ecosystem and can be a powerful +tool for users and developers who want to extend the functionality of the system. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +Apache Airflow has a number of different Public Interfaces that allow developers to interact with various +aspects of the system. Some examples of the types of Public Interfaces exposed as Python objects +that are available in Apache Airflow include: + +* `DAG `_ (Directed Acyclic Graph) APIs, which allow developers to create, manage, + and access DAGs in Airflow. +* `Task `_ APIs, which provide access to information about individual tasks within + a DAG, such as their dependencies and execution status. +* `Operator `_ APIs, which allows the developers to write their custom Operators. +* `Decorators `_ APIs, which allows the developers to write their + custom decorators to make it easier to write `TaskFlow `_ DAGs. +* `Secret Managers `_ APIs, which allows the developers to write their custom + Secret Managers to safely access credentials and other secret configuration of their workflows. +* `Connection management `_ APIs, which allow developers to manage + connections to external systems +* `XCom `_, which allow developers to manage cross-task communication within Airflow. +* `Variables `_, which allow developers to manage variables within Airflow. +* `Executors `_, which allow developers to manage the execution of tasks within Airflow. +* `Listeners `_, which allow developers to react to DAG/Task lifecycle events. +* `Plugins `_, which allow developers to extend internal Airflow capabilities - add new UI + pages, custom `TimeTables `_, `Extra Links `_, + `Triggers `_. `Listeners `_. + +What is not part of the Public Interface of Apache Airflow? +=== + +Everything not mentioned in this document should be considered as non-Public Interface. + +The users however, might have some assumptions about different parts of Airflow, thinking that +they can rely on them, so here we try to clarify and want to be explicit that they are not part of the +Public Interface: + +* `Database structure `_ is considered to be an internal implementation + detail and you should not assume the structure is going to be maintained in + backwards-compatible way. + +* `Web UI `_ is considered to be continuously adapting and evolving for Apache Airflow and + you should not assume that the UI will remain as it is in backwards-compatible way. Views and screens + might be updated and removed in major releases without impacting backwards-compatibility. + +* `Python API `_ (except the explicitly mentioned classes below), are considered an + internal implementation details and you should not assume they will be maintained + in backwards-compatible way. + +Which classes and packages are part of the Public Interface of Apache Airflow? +===
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1050144300 ## docs/apache-airflow/public-airflow-interface.rst: ## @@ -0,0 +1,115 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This can include operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +as well as for automating certain aspects of the Airflow workflow. + +In general, the Public Interface is an important part of the Airflow ecosystem and can be a powerful +tool for users and developers who want to extend the functionality of the system. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +Apache Airflow has a number of different Public Interfaces that allow developers to interact with various +aspects of the system. Some examples of the types of Public Interfaces exposed as Python objects +that are available in Apache Airflow include: + +* `DAG `_ (Directed Acyclic Graph) APIs, which allow developers to create, manage, + and access DAGs in Airflow. +* `Task `_ APIs, which provide access to information about individual tasks within + a DAG, such as their dependencies and execution status. +* `Operator `_ APIs, which allows the developers to write their custom Operators. +* `Decorators `_ APIs, which allows the developers to write their + custom decorators to make it easier to write `TaskFlow `_ DAGs. +* `Secret Managers `_ APIs, which allows the developers to write their custom + Secret Managers to safely access credentials and other secret configuration of their workflows. +* `Connection management `_ APIs, which allow developers to manage + connections to external systems +* `XCom `_, which allow developers to manage cross-task communication within Airflow. +* `Variables `_, which allow developers to manage variables within Airflow. +* `Executors `_, which allow developers to manage the execution of tasks within Airflow. +* `Listeners `_, which allow developers to react to DAG/Task lifecycle events. +* `Plugins `_, which allow developers to extend internal Airflow capabilities - add new UI + pages, custom `TimeTables `_, `Extra Links `_, + `Triggers `_. `Listeners `_. + +What is not part of the Public Interface of Apache Airflow? +=== + +Everything not mentioned in this document should be considered as non-Public Interface. + +The users however, might have some assumptions about different parts of Airflow, thinking that +they can rely on them, so here we try to clarify and want to be explicit that they are not part of the +Public Interface: + +* `Database structure `_ is considered to be an internal implementation + detail and you should not assume the structure is going to be maintained in + backwards-compatible way. + +* `Web UI `_ is considered to be continuously adapting and evolving for Apache Airflow and + you should not assume that the UI will remain as it is in backwards-compatible way. Views and screens + might be updated and removed in major releases without impacting backwards-compatibility. + +* `Python API `_ (except the explicitly mentioned classes below), are considered an + internal implementation details and you should not assume they will be maintained + in backwards-compatible way. + +Which classes and packages are part of the Public Interface of Apache Airflow? +===
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1048330340 ## docs/apache-airflow/public-airflow-interface.rst: ## @@ -0,0 +1,115 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This can include operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +as well as for automating certain aspects of the Airflow workflow. + +In general, the Public Interface is an important part of the Airflow ecosystem and can be a powerful +tool for users and developers who want to extend the functionality of the system. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +Apache Airflow has a number of different Public Interfaces that allow developers to interact with various +aspects of the system. Some examples of the types of Public Interfaces exposed as Python objects +that are available in Apache Airflow include: + +* `DAG `_ (Directed Acyclic Graph) APIs, which allow developers to create, manage, + and access DAGs in Airflow. +* `Task `_ APIs, which provide access to information about individual tasks within + a DAG, such as their dependencies and execution status. +* `Operator `_ APIs, which allows the developers to write their custom Operators. +* `Decorators `_ APIs, which allows the developers to write their + custom decorators to make it easier to write `TaskFlow `_ DAGs. +* `Secret Managers `_ APIs, which allows the developers to write their custom + Secret Managers to safely access credentials and other secret configuration of their workflows. +* `Connection management `_ APIs, which allow developers to manage + connections to external systems +* `XCom `_, which allow developers to manage cross-task communication within Airflow. +* `Variables `_, which allow developers to manage variables within Airflow. +* `Executors `_, which allow developers to manage the execution of tasks within Airflow. +* `Listeners `_, which allow developers to react to DAG/Task lifecycle events. +* `Plugins `_, which allow developers to extend internal Airflow capabilities - add new UI + pages, custom `TimeTables `_, `Extra Links `_, + `Triggers `_. `Listeners `_. + +What is not part of the Public Interface of Apache Airflow? +=== + +Everything not mentioned in this document should be considered as non-Public Interface. + +The users however, might have some assumptions about different parts of Airflow, thinking that +they can rely on them, so here we try to clarify and want to be explicit that they are not part of the +Public Interface: Review Comment: I would like to keep it and explain context. It is all about setting the expectations. I think if we do not provide that context, users might mistakenly think that this list of "things" that are excluded is "closed" (and there are no others). By explicitly explaining that here we are only showing things that some people might easily take for granted we provide more context - why we are listing those things here. We are listing them here because people might (and did) make assumptions those things are "public interface". This alreaady happened, and it is likely .o happen again. So listing those things here, we are addressing the likely case that people will attempt to rely on. This is purely based on past discussions and assumptions people alread
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1048325485 ## docs/apache-airflow/public-airflow-interface.rst: ## @@ -0,0 +1,115 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This can include operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +as well as for automating certain aspects of the Airflow workflow. + +In general, the Public Interface is an important part of the Airflow ecosystem and can be a powerful +tool for users and developers who want to extend the functionality of the system. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +Apache Airflow has a number of different Public Interfaces that allow developers to interact with various +aspects of the system. Some examples of the types of Public Interfaces exposed as Python objects +that are available in Apache Airflow include: + +* `DAG `_ (Directed Acyclic Graph) APIs, which allow developers to create, manage, + and access DAGs in Airflow. +* `Task `_ APIs, which provide access to information about individual tasks within + a DAG, such as their dependencies and execution status. +* `Operator `_ APIs, which allows the developers to write their custom Operators. +* `Decorators `_ APIs, which allows the developers to write their + custom decorators to make it easier to write `TaskFlow `_ DAGs. +* `Secret Managers `_ APIs, which allows the developers to write their custom + Secret Managers to safely access credentials and other secret configuration of their workflows. +* `Connection management `_ APIs, which allow developers to manage + connections to external systems +* `XCom `_, which allow developers to manage cross-task communication within Airflow. +* `Variables `_, which allow developers to manage variables within Airflow. +* `Executors `_, which allow developers to manage the execution of tasks within Airflow. +* `Listeners `_, which allow developers to react to DAG/Task lifecycle events. +* `Plugins `_, which allow developers to extend internal Airflow capabilities - add new UI + pages, custom `TimeTables `_, `Extra Links `_, + `Triggers `_. `Listeners `_. + +What is not part of the Public Interface of Apache Airflow? +=== + +Everything not mentioned in this document should be considered as non-Public Interface. + +The users however, might have some assumptions about different parts of Airflow, thinking that +they can rely on them, so here we try to clarify and want to be explicit that they are not part of the +Public Interface: + +* `Database structure `_ is considered to be an internal implementation + detail and you should not assume the structure is going to be maintained in + backwards-compatible way. + +* `Web UI `_ is considered to be continuously adapting and evolving for Apache Airflow and + you should not assume that the UI will remain as it is in backwards-compatible way. Views and screens + might be updated and removed in major releases without impacting backwards-compatibility. + +* `Python API `_ (except the explicitly mentioned classes below), are considered an + internal implementation details and you should not assume they will be maintained + in backwards-compatible way. + +Which classes and packages are part of the Public Interface of Apache Airflow? +===
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1047364387 ## docs/apache-airflow/public-airflow-interface.rst: ## @@ -0,0 +1,110 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This can include operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +as well as for automating certain aspects of the Airflow workflow. + +In general, the Public Interface is an important part of the Airflow ecosystem and can be a powerful +tool for users and developers who want to extend the functionality of the system. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +Apache Airflow has a number of different Public Interfaces that allow developers to interact with various +aspects of the system. Some examples of the types of Public Interfaces exposed as Python objects +that are available in Apache Airflow include: + +* `DAG `_ (Directed Acyclic Graph) APIs, which allow developers to create, manage, + and access DAGs in Airflow. +* `Task `_ APIs, which provide access to information about individual tasks within + a DAG, such as their dependencies and execution status. +* `Operator `_ APIs, which allows the developers to write their custom Operators. +* `Decorators `_ APIs, which allows the developers to write their + custom decorators to make it easier to write `TaskFlow `_ DAGs. +* `Secret Managers `_ APIs, which allows the developers to write their custom + Secret Managers to safely access credentials and other secret configuration of their workflows. +* `Connection management `_ APIs, which allow developers to manage + connections to external systems +* `XCom `_, which allow developers to manage cross-task communication within Airflow. +* `Variables `_, which allow developers to manage variables within Airflow. +* `Executors `_, which allow developers to manage the execution of tasks within Airflow. +* `Listeners `_ - all of which are considered Public Interfaces. +* `Plugins `_, which allow developers to extend internal Airflow capabilities - add new UI + pages, custom `TimeTables `_, `Extra Links `_, + +What is not part of the Public Interface of Apache Airflow? +=== + +Everything not mentioned in this document should be considered as non-Public Interface. + +The users however, might have some assumptions about different parts of Airflow, thinking that +they can rely on them, so here we try to clarify and want to be explicit that they are not part of the +Public Interface: + +* `Database structure `_ is considered to be an internal implementation + detail and you should not assume the structure is going to be maintained in + backwards-compatible way. + +* `Web UI `_ is considered to be continuously adapting and evolving for Apache Airflow and + you should not assume that the UI will remain as it is in backwards-compatible way. Views and screens + might be updated and removed in major releases without impacting backwards-compatibility. + +* `Python API `_ (except the explicitly mentioned classes below), are considered an + internal implementation details and you should not assume they will be maintained + in backwards-compatible way. + +Which classes and packages are part of the Public Interface of Apache Airflow? +==
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1047362049 ## docs/apache-airflow/public-airflow-interface.rst: ## @@ -0,0 +1,110 @@ + .. Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + +Public Interface of Airflow +=== + +The Public Interface of Apache Airflow is a set of programmatic interfaces that allow developers to interact +with and access certain features of the Apache Airflow system. This can include operations such as +creating and managing DAGs (directed acyclic graphs), managing tasks and their dependencies, +and extending Airflow capabilities by writing new executors, plugins, operators and providers. The +Public Interface can be useful for building custom tools and integrations with other systems, +as well as for automating certain aspects of the Airflow workflow. + +In general, the Public Interface is an important part of the Airflow ecosystem and can be a powerful +tool for users and developers who want to extend the functionality of the system. + +You can extend Airflow in three ways: + +* By writing new custom Python code (via Operators, Plugins, Provider) +* By using the `Stable REST API `_ (based on the OpenAPI specification) +* By using the `Airflow Command Line Interface (CLI) `_ + +How can you extend Apache Airflow with custom Python Code? +== + +Apache Airflow has a number of different Public Interfaces that allow developers to interact with various +aspects of the system. Some examples of the types of Public Interfaces exposed as Python objects +that are available in Apache Airflow include: + +* `DAG `_ (Directed Acyclic Graph) APIs, which allow developers to create, manage, + and access DAGs in Airflow. +* `Task `_ APIs, which provide access to information about individual tasks within + a DAG, such as their dependencies and execution status. +* `Operator `_ APIs, which allows the developers to write their custom Operators. +* `Decorators `_ APIs, which allows the developers to write their + custom decorators to make it easier to write `TaskFlow `_ DAGs. +* `Secret Managers `_ APIs, which allows the developers to write their custom + Secret Managers to safely access credentials and other secret configuration of their workflows. +* `Connection management `_ APIs, which allow developers to manage + connections to external systems +* `XCom `_, which allow developers to manage cross-task communication within Airflow. +* `Variables `_, which allow developers to manage variables within Airflow. +* `Executors `_, which allow developers to manage the execution of tasks within Airflow. +* `Listeners `_ - all of which are considered Public Interfaces. +* `Plugins `_, which allow developers to extend internal Airflow capabilities - add new UI + pages, custom `TimeTables `_, `Extra Links `_, + +What is not part of the Public Interface of Apache Airflow? +=== + +Everything not mentioned in this document should be considered as non-Public Interface. + +The users however, might have some assumptions about different parts of Airflow, thinking that +they can rely on them, so here we try to clarify and want to be explicit that they are not part of the +Public Interface: + +* `Database structure `_ is considered to be an internal implementation + detail and you should not assume the structure is going to be maintained in + backwards-compatible way. + +* `Web UI `_ is considered to be continuously adapting and evolving for Apache Airflow and + you should not assume that the UI will remain as it is in backwards-compatible way. Views and screens + might be updated and removed in major releases without impacting backwards-compatibility. + +* `Python API `_ (except the explicitly mentioned classes below), are considered an + internal implementation details and you should not assume they will be maintained + in backwards-compatible way. + +Which classes and packages are part of the Public Interface of Apache Airflow? +==
[GitHub] [airflow] potiuk commented on a diff in pull request #28300: Add Public Interface description to Airflow documentation
potiuk commented on code in PR #28300: URL: https://github.com/apache/airflow/pull/28300#discussion_r1047336269 ## docs/apache-airflow/index.rst: ## @@ -79,6 +79,48 @@ seen running over time: Each column represents one DAG run. These are two of the most used views in Airflow, but there are several other views which allow you to deep dive into the state of your workflows. +Customizing Airflow +=== + +There are several ways to extend the capabilities of Apache Airflow: + +* Writing `Custom Operators `_ : Operators are the building blocks of DAGs in + Airflow, and can be used to perform specific tasks within a DAG. By writing custom operators, + you can add new functionality to Airflow, such as the ability to connect to and interact + with external services, or to perform complex data transformations. + +* Writing `Custom Decorators `_ : Custom decorators are a way to + extend the functionality of the Airflow ``@task`` decorator. By writing custom decorators, + you can add new functionality to Airflow, such as the ability to connect to and interact + with external services, or to perform complex data transformations. + +* Creating custom :doc:`plugins`: Airflow plugins are extensions to the core system that provide additional + features and functionality. By creating custom plugins, you can add new capabilities to Airflow, + such as adding custom UI components, creating custom macros, creating your own TimeTables, + adding Operator Extra Links, Listeners. + +* Writing custom `provider packages `_: Providers are the components + of Airflow that are responsible for connecting to and interacting with external services. By writing + custom providers, you can add support for new types of external services, such as databases or + cloud services, to Airflow. Review Comment: Yep. Good idea. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@airflow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
