postgres provider: use non-binary psycopg2

[brki]

The non-binary version of psycopg2 is now used, and the version requirement changed to psycopg2>=2.8.0.
The non-binary version is used because the binary version of psycopg2 is not recommended for production
use. The minimum version of psycopg2 was changed because psycopg2 < 2.8.0 includes a binary distribution
which will be installed by default.
If not already present, you will need to add the postgresql development libraries. On debian-based systems,
this is provided by the package libpq-dev.

Closes: #25712

---

^ Add meaningful description above

Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contribution Guide (https://github.com/apache/airflow/blob/main/CONTRIBUTING.rst)
Here are some useful points:

• Pay attention to the quality of your code (flake8, mypy and type annotations). Our pre-commits will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[RosterIn]

I think this file is generated automatically so you shouldn't edit it

[potiuk]

@RosterIn is right. see note just abiive:

Please, only add notes to the Changelog just below the "Changelog" header when there are some breaking changes
and you want to add an explanation to the users on how they are supposed to deal with them.
The changelog is updated and maintained semi-automatically by release manager.

Also I think the change is not breaking. Dependency change is not a breaking change, bumping min version is not breaking either, and the behaviour is not going to change either

[brki]

Thanks @RosterIn , I've removed the changes to index.rst.

[brki]

@potiuk I considered it a breaking change because it will break for some people, because it introduces new operating system dependencies, that were not necessarily present before. For example on Debian-based distros, libpq-dev is necessary. This is the case for the slim docker images, for example airflow:slim-2.3.3-python3.10 .

[potiuk]

This is not what we consider as breaking. Dependency changes are not introducing. Our SemVer rules state (see readme)

Airflow: SemVer rules apply to core airflow only (excludes any changes to providers). Changing limits for versions of Airflow dependencies is not a breaking change on its own.

And while this is not changing the version but other 'variant' of the same dependency, this only affect how you install airflow. And it is not breaking the 'use' of Airflow which is the important factor for breaking/non breaking decision.

The main thing here that changes that are only affecting the way how you install Airfloe are not really 'breaking' any user code or ways how you use airflow. If for any reason you cannot install Airflow new version, you just cannot install it and you don't break anything. Once you installed it, it works without changes. So it does not break anything.

If you follow the logic of 'dependencies are breaking changes' then it basically would mean than any release where any dependency change is breaking - because it might cause troubles when installing Airflow or providers.

[brki]

OK. Thanks for the explanation! I'll adjust it later.

…

On Sat, 20 Aug 2022, 11:22 Jarek Potiuk ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In docs/apache-airflow-providers-postgres/index.rst <#25710 (comment)>: > @@ -65,7 +65,7 @@ Package apache-airflow-providers-postgres `PostgreSQL <https://www.postgresql.org/>`__ -Release: 5.2.0 +Release: 6.0.0 This is not what we consider as breaking. Dependency changes are not introducing. Our SemVer rules state (see readme) Airflow: SemVer rules apply to core airflow only (excludes any changes to providers). Changing limits for versions of Airflow dependencies is not a breaking change on its own. And while this is not changing the version but other 'variant' of the same dependency, this only affect how you install airflow. And it is not breaking the 'use' of Airflow which is the important factor for breaking/non breaking decision. The main thing here that changes that are only affecting the way how you install Airfloe are not really 'breaking' any user code or ways how you use airflow. If for any reason you cannot install Airflow new version, you just cannot install it and you don't break anything. Once you installed it, it works without changes. So it does not break anything. If you follow the logic of 'dependencies are breaking changed' then it basically would mean than any release where any dependency change is breaking - because it might cause troubles when installing Airflow or providers. — Reply to this email directly, view it on GitHub <#25710 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFKHGHUKE2TMV6P6DHE6ALV2CPUTANCNFSM56PS4F6A> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[potiuk]

Cool!

[boring-cyborg]

Awesome work, congrats on your first merged pull request!