chore: Force grpcio-tools dev dependency to <1.66.0 to allow grpcio compatibility with <1.66.0

[josephsw]

Description

This PR bumps down the dev dependency grpcio-tools to <1.66.0 to allow grpcio compatibility with <1.66.0.

This compatibility seems to have been broken in pydgraph 24.0.2 by #255 (where regenerating the protobuf sources with grpcio-tools >= 1.66.0 changed the warning in api_pb2_grpc.py to a RuntimeError).

Example error:

RuntimeError: The grpc package installed is at version 1.65.5, but the generated code in api_pb2_grpc.py depends on grpcio>=1.71.0. Please upgrade your grpc module to grpcio>=1.71.0 or downgrade your generated code using grpcio-tools<=1.65.5.

Addresses #222, related to #233

Changes

• Downgraded grpcio-tools dev dependency from grpcio-tools>=1.68.0 to grpcio-tools>=1.65.0,<1.66.0
• Regenerated protobuf source files (python scripts/protogen.py)

Rationale (adapted from #233)

• Flexibility: This change allows the library to be compatible with a wider range of versions, making it easier to integrate into projects with different dependency requirements.
  • Any project currently using Apache Beam (as of July 2025) is stuck on grpcio < 1.66.0 due to this open issue with tests (since September 2024): [Python] Significant test flakiness after upgrading to grpcio 1.66.0  grpc/grpc#37710
• Compatibility: Minor and patch versions are generally backward compatible. Allowing updates within these ranges enables the library to benefit from bug fixes and improvements.
• Ease of Integration: Reduces the likelihood of version conflicts, promoting smoother integration and wider adoption.
• Lack of necessity: The compiled output protobuf files are identical between the older version of grpcio-tools and the newer version, meaning this forced version bump is not currently required

Checklist

• Code compiles correctly and linting passes locally
• For all code changes, an entry added to the CHANGELOG.md file describing and linking to
  this PR
• Tests added for new functionality, or regression tests for bug fixes added as applicable
• For public APIs, new features, etc., PR on
  docs repo staged and linked here

[Copilot]

Pull Request Overview

This PR addresses a compatibility issue with gRPC dependencies by constraining the grpcio-tools dev dependency to versions below 1.66.0, allowing the library to work with projects that require grpcio < 1.66.0. The change resolves a RuntimeError that was introduced in version 24.0.2 when protobuf sources were regenerated with newer grpcio-tools.

• Constrained grpcio-tools dev dependency from >=1.68.0 to >=1.65.0,<1.66.0
• Regenerated protobuf source files to use older gRPC tooling that emits warnings instead of RuntimeErrors
• Updated changelog to document the compatibility fix

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
pyproject.toml	Updated grpcio-tools version constraint with explanatory comment
pydgraph/proto/api_pb2_grpc.py	Regenerated gRPC code that uses warnings instead of RuntimeError for version mismatches
pydgraph/proto/api_pb2.py	Regenerated protobuf code with older tooling version
CHANGELOG.md	Added changelog entry documenting the compatibility fix

[josephsw]

Looks like the Python 3.13 CI test breaks because grpc only added support for it in 1.66.2...
grpc/grpc#34922

[matthewmcneely]

Looks like the Python 3.13 CI test breaks because grpc only added support for it in 1.66.2... grpc/grpc#34922

Right, we discussing internally dropping 3.13 support. Don't think many people are using in production as 3.12 is the official "LTS"

[matthewmcneely]

Note: I successfully tested this pydgraph branch against Dgraph versions: v25.0.0-preview6, v24.1.2 and v23.1.1

[mattjohnsonpint]

Please hold on this until we've had a chance to discuss internally. Thanks.

[josephsw]

Looks like the Python 3.13 CI test breaks because grpc only added support for it in 1.66.2... grpc/grpc#34922

Right, we discussing internally dropping 3.13 support. Don't think many people are using in production as 3.12 is the official "LTS"

I don't think you necessarily need to drop Python 3.13 support - I've pushed a commit that readds support for Python 3.13, but skips the protogen diff step in the CI tests for 3.13.

[matthewmcneely]

I don't think you necessarily need to drop Python 3.13 support - I've pushed a commit that readds support for Python 3.13, but skips the protogen diff step in the CI tests for 3.13.

Ah, of course. Thanks for pointing that out... the diff checks will happen in the other build steps.

[mattjohnsonpint]

Hi folks. This PR doesn't sit well with me, for a few reasons:

• Python 3.13 is the current stable version of Python. It is what new Python users are given by default, and is absolutely supported by the Python authors. It is labeled "bugfix" because bugs that are reported and verified will be fixed in a patch version of this series. Releases labeled "security" are LTS (long-term support) relases, and thus only receive security-related fixes. This is on par with how other communities such as Node.js and .NET operate.
• While it's true than many people chose to ship LTS versions to production rather than the current release - we cannot simply decide to stop supporting non-LTS versions. That would be problematic for many reasons.
• Ideally, we'd also strive to support pre-release versions (ie, 3.14), perhaps via pre-release versions of PyDgraph - but that is not a hard requirement. The main purpose of the pre-release period is to use for testing, to ensure that we're ready to support 3.14 when it becomes the current release (scheduled for 2025-10-07).
• The last commit made doesn't resolve the core issue, it just sidesteps it by skipping protobuf generation. It also makes the rest of the PR inconsistent (ie., title, description, changelog, etc.)

I'm closing this PR. We should take a closer look at solving the underlying issue, such that we can properly support 3.12 and earlier, as well as 3.13 (and newer, as time progresses). If that means we have to branch the code somewhere, or the workflow, that's fine - but we can't simply sidestep it. Let's work on that in a new PR.

Thanks.

[josephsw]

This has been reimplemented in #272