TF2.16 support: hermetic python shim, TF 2.16.2 pin, legacy Keras path, setup/packaging fixes

[psamanoelton]

Summary

• Enable building TFQ against TensorFlow 2.16.2 with Bazel 6.5.x
• Keep Keras 2 (“tf-keras”) path via TF_USE_LEGACY_KERAS=1 to avoid Keras 3 breakages
• Allow selecting system/venv/conda Python; wire that interpreter through Bazel
• Make wheel-build script honor chosen Python and include setuptools

Key changes

• WORKSPACE: bump @org_tensorflow to 2.16.2, add a tiny @python local_repository shim
• third_party/python_legacy/defs.bzl: export interpreter as a string (what TF’s local_config_python expects)
• configure.sh: --python= flag; generate .tf_configure.bazelrc + .bazelrc + the python shim
• .bazelrc: ensure TF_USE_LEGACY_KERAS=1 for build/test; keep existing warnings/rpath tweaks
• release/build_pip_package.sh: invoke ${PYTHON_BIN_PATH:-python3} and ensure setuptools present
• setup.py: (optionally) relax deps to run on TF 2.16 (sympy==1.14); extras pin tensorflow==2.16.0

Testing

• Linux/Ubuntu 22.04 (Docker), Python 3.11, Bazelisk → Bazel 6.5.0
• bazel build ... release:build_pip_package succeeds
• Unit tests (scripts/test_all.sh) pass with
• Wheel installs and imports with TF 2.16.2 + tf-keras 2.16.0, Cirq 1.3.0, NumPy 1.26.4

Notes

• This keeps TFQ on Keras 2 path; Keras 3 migration can be handled in a a future PR.
• This changes will help on the incoming upgrades to 2.20.

[mhucka]

Thank you for the work, and I'm sorry about the number of changes requested here …

[samanoelton]

About the version used here (0.7.5):

I put 0.7.5 because in the master branch in releases/setup.py:

quantum/release/setup.py

Line 58 in c6a90ac

CUR_VERSION = '0.7.4'

It was 0.7.4

As you mentioned the current version on PyPi is 0.7.3... I could patch releases/setup.py and tensorflow_quantum/init.py to match 0.7.4

(init has 0.7.2):

quantum/tensorflow_quantum/__init__.py

Line 67 in c6a90ac

__version__ = '0.7.2'

And maybe this new version could be the tag 0.7.4 right?

Or maybe the current version that is in master is the unofficial version 0.7.4 and I should update it to 0.7.5? (to avoid losing 0.7.4 that is in master).

[mhucka]

About the version used here (0.7.5):

I put 0.7.5 because in the master branch in releases/setup.py:

quantum/release/setup.py

Line 58 in c6a90ac

CUR_VERSION = '0.7.4'

It was 0.7.4

As you mentioned the current version on PyPi is 0.7.3... I could patch releases/setup.py and tensorflow_quantum/init.py to match 0.7.4

(init has 0.7.2):

quantum/tensorflow_quantum/__init__.py

Line 67 in c6a90ac

__version__ = '0.7.2'

And maybe this new version could be the tag 0.7.4 right?

Or maybe the current version that is in master is the unofficial version 0.7.4 and I should update it to 0.7.5? (to avoid losing 0.7.4 that is in master).

I know we discussed this offline, but just to follow up here too for future reference:

The 0.7.4 in main is intended to be the next version. I'm not sure if this convention is different from what TensorFlow does, but the convention for TFQ has been that main on GitHub contains the working (i.e., in-development) version. When a release is made, that's the version that it gets, and immediately after the release, the version number is bumpted up. This indicates the next version being worked on.

For TFQ, since the last release was for 0.7.3, the version was bumped in main to 0.7.4 after the release, and no releases have happened since that one. So the next release is 0.7.4.

Based on the PR the version number was bumped to 0.7.4 after the last release, it looks like the version number was updated to 0.7.4 only in setup.py, and the version number in the file tensorflow_quantum/__init__.py was left at 0.7.2. I guess that must have been an oversight at the time. That would account for the discrepancy.

At some point in the future, I think we should change the numbering scheme to include .dev0 in the version number in main. The other projects like Cirq have adopted that convention. It makes it more clear what the version number in main means.