thank you!

I would suggest, actually upgrading all grpc python packages at once.

So the additional packages not mentioned in the comment (including your commit) would be:

• pythonPackages.grpcio-testing
• pythonPackages.grpcio-channelz
• pythonPackages.grpcio-reflection
• pythonPackages.grpcio-health-checking

Its probably also a good idea to add 'noupdate' to these packages so that r-ryantm doesn't update them individually.

I would suggest, actually upgrading all grpc python packages at once.

Sounds like a wise thing to do. I added the python packages you mentioned to the comment and disabled auto updates for them as well as the main grpc package. Looking at the logs, r-ryantm cannot update it ultimately anyway (e.g. here).

I decided to add a test that checks whether the related python packages have the same version as grpc. The test will fail with an error message, if any version doesn't match

error: builder for '/nix/store/qcwpwsk0arvszv23b9yg72b5kzv7gil8-check-grpc-versions.drv' failed with exit code 1;
       last 2 log lines:
       > Version of package python3.12-grpcio-1.64.1 does not match this grpc version (1.66.1)
       > Please ensure that all related packages have the same version
       For full logs, run 'nix log /nix/store/qcwpwsk0arvszv23b9yg72b5kzv7gil8-check-grpc-versions.drv'.

The test will obviously fail currently, but should pass once all packages have the same version and will help to prevent incompatibilities in the future. I don't feel to good about merging a failing test but I think it makes sense in this context. Let me know if you have concerns.

The test will obviously fail currently, but should pass once all packages have the same version and will help to prevent incompatibilities in the future. I don't feel to good about merging a failing test but I think it makes sense in this context. Let me know if you have concerns.

Great idea! I believe merging now should not be a problem. Since the latest version is 1.66.2 now anyways, I think we should create a PR updating all packages once this one is merged.

Did you consider perhaps having more of a "functional" test

I agree that functional tests should be the desired solution, however, I am not familiar at all with the python grpc stuff and adding the tests out of the initial scope of this PR, which was just adding the comments. I crated a separate issue that can help in tracking the progress of compatibility tests: #351132

PR title needs to be adjusted, looks good otherwise!