Bump cattrs version

[tomsej]

related: #24421

---

^ 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

[ashb]

Sounds good to me, but haven't checked anything in detail here.

Have you checked the changelog of cattrs to see if anything is likely to break for us?

[tomsej]

Sounds good to me, but haven't checked anything in detail here.

Have you checked the changelog of cattrs to see if anything is likely to break for us?

Honestly, it is hard to say. Previously, it broke a lineage (#16172), but it should be fixed in python-attrs/cattrs#151. There is also a new validation mode https://cattrs.readthedocs.io/en/latest/validation.html but I do not think it should break anything.

Build is failing but it seems to be unrelated to my changes. Is there anything I can do to move it forward?

[ashb]

#56 144.0 error: Command "gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -DNPY_INTERNAL_BUILD=1 -DHAVE_NPY_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -Ibuild/src.linux-x86_64-3.10/numpy/core/src/umath -Ibuild/src.linux-x86_64-3.10/numpy/core/src/npymath -Ibuild/src.linux-x86_64-3.10/numpy/core/src/common -Inumpy/core/include -Ibuild/src.linux-x86_64-3.10/numpy/core/include/numpy -Inumpy/core/src/common -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -I/usr/local/include/python3.10 -Ibuild/src.linux-x86_64-3.10/numpy/core/src/common -Ibuild/src.linux-x86_64-3.10/numpy/core/src/npymath -c build/src.linux-x86_64-3.10/numpy/core/src/multiarray/scalartypes.c -o build/temp.linux-x86_64-3.10/build/src.linux-x86_64-3.10/numpy/core/src/multiarray/scalartypes.o -MMD -MF build/temp.linux-x86_64-3.10/build/src.linux-x86_64-3.10/numpy/core/src/multiarray/scalartypes.o.d -std=c99" failed with exit status 1

Build error is caused by trying to build numpy on 3.10 (numpy still doesn't have a wheel for 3.10?!)

[ashb]

Hmm, recent versions do, but we tried to pull in numpy==1.19.4, but that is not what's in any of the constraint files https://github.com/apache/airflow/blob/constraints-main/constraints-3.10.txt -- any idea why that might be @potiuk ?

[potiuk]

Build error is caused by trying to build numpy on 3.10 (numpy still doesn't have a wheel for 3.10?!)

Bumping cattrs unblocked numpy to be bumped to 1,23.* (from 1.22.4) which apparently has problem with 3,10. I thin k 1.22.4 also does not support 3.10 fully - but it did not have a detection of that 🤷

numpy is only needed in oracle provider it seems (BTW. we should get rid of it - I believe it is only needed there to do detection

The solution @romsej will be to change in https://github.com/apache/airflow/blob/main/airflow/providers/oracle/provider.yaml

dependencies:
   - numpy 

to:

dependencies:
   - numpy;python_version<"3.10"
   - numpy<1.23;python_version>="3.10"

But I will try to get rid of it completely in parallel anyway

[potiuk]

Ah noo.... numpy==1.19.4 :...... This is strange.

[tomsej]

I do not think that is the case. Seems some other builds are also failing - https://github.com/apache/airflow/runs/7806805101?check_suite_focus=true#step:13:19601. I cannot investigate since I am not by the computer.

[potiuk]

Yeah. Lookiung at it

[potiuk]

This is a more complex issue - looks like pip resolver started to downgrade our pyarrow for 3.10 which triggered downgrading numpy :)

[tomsej]

Ohh, thanks a lot! Let me know if I can help...

[potiuk]

Fix here #25697 - once it gets green and get merged please rebase @tomsej :)

[potiuk]

Ok. I merged the fix and rebased your PR on top @tomsej - let's see :)

[tomsej]

@potiuk thanks a lot, I really appreciate it! It failed on binding address for Trino:

ERROR: for airflow-integration-postgres_trino_1 Cannot start service trino: driver failed programming external connectivity on endpoint airflow-integration-postgres_trino_1 (50f5ffd5c1adb15ff3699b0b430ad1b8ae39296afe40f7cb5d97eaae97dc58ad): Error starting userland proxy: listen tcp4 0.0.0.0:38080: bind: address already in use

Do I need to rerun the tests? Dziękuję bardzo :)

[potiuk]

I re-run it :)

[boring-cyborg]

Awesome work, congrats on your first merged pull request!