potiuk commented on code in PR #45259: URL: https://github.com/apache/airflow/pull/45259#discussion_r1907964190
########## providers/airbyte/pyproject.toml: ########## @@ -0,0 +1,73 @@ + +# 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. + +# NOTE! THIS FILE IS AUTOMATICALLY GENERATED AND WILL BE OVERWRITTEN! + +# IF YOU WANT TO MODIFY THIS FILE, YOU SHOULD MODIFY THE TEMPLATE +# `pyproject_TEMPLATE.toml.jinja2` IN the `dev/breeze/src/airflow_breeze/templates` DIRECTORY +[build-system] +requires = ["flit_core==3.10.1"] +build-backend = "flit_core.buildapi" + +[project] +name = "apache-airflow-providers-airbyte" +version = "5.0.0" +description = "Provider package apache-airflow-providers-airbyte for Apache Airflow" +readme = "README.rst" +authors = [ + {name="Apache Software Foundation", email="[email protected]"}, +] +maintainers = [ + {name="Apache Software Foundation", email="[email protected]"}, +] +keywords = [ "airflow-provider", "airbyte", "airflow", "integration" ] +classifiers = [ + "Development Status :: 5 - Production/Stable", + "Environment :: Console", + "Environment :: Web Environment", + "Intended Audience :: Developers", + "Intended Audience :: System Administrators", + "Framework :: Apache Airflow", + "Framework :: Apache Airflow :: Provider", + "License :: OSI Approved :: Apache Software License", + "Programming Language :: Python :: 3.9", + "Programming Language :: Python :: 3.10", + "Programming Language :: Python :: 3.11", + "Programming Language :: Python :: 3.12", + "Topic :: System :: Monitoring", +] +requires-python = "~=3.9" +dependencies = [ + "apache-airflow>=2.9.0", + "airbyte-api>=0.52.0", +] Review Comment: Very good question - not stupid at all because this is not at all obviois but - there are few reasons. BTW. I have not planned doing it but while implementing it I found quite a few reasons why its better to just regenerate it. * First of all, there is a problem with versions in URLs - we link to the version of Provider in the URLs directly embedded in pyproject.toml and some of the URLs contains versions of provider (for example link to documentation). Those cannot be templated, we could make them potentially dynamic via "hatch_build" or similar but that's not really worth the effort. * Secondly - we have support for different Python versions in different providers (currently we keep python excludes in Provider.yaml - and this will become very useful when we add Python 3.13 support). While we could rely on trove classifiers as a source of truth, there is a number of CI scripts and breeze ifs that depend on python versions supported in provider and implement skipping or removing the providers, having a single source of truth in `provider.yaml` with exceptions from the "currently supported Python versions list" is way more convenient - there are few providers to have those exceptions usually and we can manage it more easily. * Also in the future we would like to apply some common changes to all providers (say for example flit_core version bump). Also we might add - in the future - different way of referring to workspace projects, regenerating pyproject.toml in this case is quite a bit better than only modifying parts of it in 90+ provider packages. * Finally it's much more maintainable for our 90+ providers to have one place where the "main" template for all pyproject.toml files for provider is kept and always override the pyproject.toml using it. Otherwise there is a temptation taht if somone wants to do a quick-fix and add single provider feature/exception in it's provider.yaml - it could be added in a way that will prevent global changes to work - some of those 90+ pyproject.toml might diverge in differnt direction, that we won't be able to converge. So - it's much better to always regenerate them. This way you will prevent people from making "quick" changes - they will always have to add the changes in more maintainable way - they will have to implement the template changes so that whatever they implement in the single provider could be re-applied to others. Which will automatically keep all the 90+ providers maintainable in a "common" way in the future. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
