Get airflow version from importlib.metadata rather than hard-coding

[ashb]

One less thing to change, and one less pre-commit step needed :)

---

^ Add meaningful description above

Read the Pull Request Guidelines for more information.
In case of fundamental code change, 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 UPDATING.md.

[ashb]

(This line isn't strictly needed, it was just so that the only symbol in this module was version. For no god reason really)

[potiuk]

Cool! This is so much better in this direction than previously !

[potiuk]

I looked more closely and we need to change it in few more places. Comment follows.

[potiuk]

We should fix it in few other places as well:

• scripts/ci/provider_packages/ci_install_and_test_provider_packages.sh -> it can be removed, it was needed because setup.py imported it before
• Dockerfile.ci -> ditto
• STATIC_CODE_CHECKS.rst has reference to removed pre-commit rule
• dev/README.md needs to be updated
• dev/README_RELEASE_AIRLFOW.md as well
• dev/provider_packages/enter_breeze_provider_package_tests.sh also can be removed as it was needed only for setup.py
• scripts/ci/libraries/_initialization.sh - it reads version from airflow/version.py, it should from setup.py, also it uses airfflow/version.py in calculation of md5sum of files for which changes trigger the build (includes comment about the mechanism)

[ashb]

Cool, I'll update those use cases.

[ashb]

scripts/ci/libraries/_initialization.sh - it reads version from airflow/version.py, it should from setup.py

We could use python setup.py --version, but do we have enough of a python environment wherever that is run? I feel we should, all it needs is setuptools.

Pushed a fixup with that -- lets see what happens.

[potiuk]

I'd prefer not to run Python here if possible. While this is a reasonable expectation that Python is installed in the hos, there are still some cases where people will have python2 by default for example and i would rather keep it bash only. There is another case in the future where we will use those scripts in code spaces environment and vs code to run docker-only environment and i would not like to have to depend on Python there.

[ashb]

Sure.

[ashb]

scripts/ci/libraries/_initialization.sh: line 138: python: command not found

Failed anyway :)

[potiuk]

Of course that all untill we rewrite breeze in python - which might change the whole approach: #12282

[potiuk]

scripts/ci/libraries/_initialization.sh - it reads version from airflow/version.py, it should from setup.py

We could use python setup.py --version, but do we have enough of a python environment wherever that is run? I feel we should, all it needs is setuptools.

Pushed a fixup with that -- lets see what happens.

As commented - i'd prefer base it on having POSIX compliant OS simply.

[mik-laj]

I'm not sure, but Google tried to use a similar trick and it causes problems.
googleapis/google-api-python-client#876

[ashb]

I'm not sure, but Google tried to use a similar trick and it causes problems.
googleapis/google-api-python-client#876

That seems specific to using Pyinstaller

[potiuk]

I'm not sure, but Google tried to use a similar trick and it causes problems.
googleapis/google-api-python-client#876

That seems specific to using Pyinstaller

Yeah. I would not worry about it. At worst, it might only cause problems in the dev environment. If we find some, we can always catch any exceptions and make a workaround for dev-only env.

[github-actions]

The PR most likely needs to run full matrix of tests because it modifies parts of the core of Airflow. However, committers might decide to merge it quickly and take the risk. If they don't merge it quickly - please rebase it to the latest master at your convenience, or amend the last commit of the PR, and push it with --force-with-lease.