feat: Add Python 3.14 support

[chalmerlowe]

This commit adds support for Python 3.14 to the library.

The following changes were made:

• Added a 3.14 trove classifier in setup.py.
• Added a grpcio version constraint for Python 3.14 in setup.py.
• Added a 3.14 presubmit configuration file in .kokoro/samples.
• Added a constraints-3.14.txt file.
• Updated the CONTRIBUTING.rst file to include 3.14.
• Updated the README.rst file to include 3.14.
• Updated owlbot.py to include "3.14" in unit_test_python_versions.
• Updated noxfile.py to include "3.14" in UNIT_TEST_PYTHON_VERSIONS and the prerelease_deps session.
• Fixed a flaky test in tests/unit/pubsub_v1/publisher/test_publisher_client.py.

[chalmerlowe]

@jules
please take a look at the multiple files in .kokoro/samples/python-3.13.
Please update the directory .kokoro/samples/python-3.14 to match (add and/or edit files appropriately).

[abbrowne126]

I believe the build issue has to do with py3.7 support as per offline discussions with @parthea. He mentioned we can remove these unit tests from the kokoro build pipeline, but is it preferable for py3.7 to be dropped as part of the py3.14 support?

[daniel-sanche]

I think you'll also need to update sync-repo-settings to make 3.14 a required check

It looks like the 3.14 tests aren't even appearing in the test list currently though. I'm not sure why that would be

[daniel-sanche]

Is this needed in the constraints file? I thought since it's in the setup.py, we'd expect this to be constrained by default.

If I understand correctly, having this as an explicit constraint might actually make us miss bugs, because we're now installing the library with a non-default configuration

[chalmerlowe]

To your point:

having this as an explicit constraint might actually make us miss bugs, because we're now installing the library with a non-default configuration

First, with a broad range of allowable dependencies in setup.py (which we want as a library others will consume) we have no control over what is a default configuration. The pip resolver could choose any number of combinations of dependencies. There is no such thing as a default unless you pin to exact versions.

Second, the requirement that "grpcio >= 1.75.1 is the same lower bound in setup.py and in constraints.txt and it is used only for cases where Python runtime 3.14 is installed, because this limitation is in the constraints-3.14.txt file and because we have conditional logic in the setup.py file to check for runtimes. In this case, the lower bounds are identical. Often constraints pin very specific versions of dependencies, but we have chosen to put a lower bound instead of an exact pin.

Thus, I could go either way (keep the constraint OR ditch it).

For context: Pip resolves dependencies per requirements in setup.py (or pyproject.toml) and as a widely used library we strive to keep that range of available dependencies as wide as possible to ensure we minimize dependency conflicts. Constraints files do NOT impact builds unless the user specifically tells pip to use them in the resolution process by passing in the --constraints or -c argument (i.e. pip install my_package -c constraints.txt). I acknowledge that we currently capture the need for a version >= x in the setup.py file so theoretically we don't need to include anything in a constraints.txt.

However: having the value in the constraints.txt file does several things:

• It provides the user with a clear picture of known good configurations that we have "tested against" (i.e. in our noxfiles we explicitly tell nox to install using constraints.txt). Now, this would be more precise if we pinned to a specific version in the constraint file, but we aren't doing that here.
• It serves as a redundancy against unexpected or accidental changes to the ranges delimited in setup.py.

[daniel-sanche]

Yeah, I'm not too worried either way. As you say, the bounds in the constraints and the setup are identical, so it feels like having this here is unnecessary, but not a problem either

It serves as a redundancy against unexpected or accidental changes to the ranges delimited in setup.py.

This situation was the concern I had in mind though. If we accidentally lost the grpc version requirement somehow, the tests would still pass because of this constraint, even though real users would run into issues. It seems safer to have the tests fail in that situation, I don't think we'd want redundancy

[daniel-sanche]

One more thing I ran into to hopefully save you some time: You'll need to update this list to skip the cpp unit tests

I did this:

py_version = tuple([int(v) for v in session.python.split(".")])
if protobuf_implementation == "cpp" and py_version >= (3, 11):
    session.skip("cpp implementation is not supported in python 3.11+")

[chalmerlowe]

One more thing I ran into to hopefully save you some time: You'll need to update this list to skip the cpp unit tests

I did this:

py_version = tuple([int(v) for v in session.python.split(".")])
if protobuf_implementation == "cpp" and py_version >= (3, 11):
    session.skip("cpp implementation is not supported in python 3.11+")

I feel like the code incorporates an adequate check for python versions:

if protobuf_implementation == "cpp" and session.python in (
    "3.11",
    "3.12",
    "3.13",
    "3.14",
):
    # do the things.

[daniel-sanche]

I feel like the code incorporates an adequate check for python versions:

if protobuf_implementation == "cpp" and session.python in (
    "3.11",
    "3.12",
    "3.13",
    "3.14",
):
    # do the things.

Oh nevermind, I must have been looking at the wrong branch, ignore my comment. On bigtable, we use a custom noxfile, so I had to address this manually