confused about version numbers, pypi and tags, minor issues and questions

[Greg Troxel]

I've arrived here because Home Assistant 2025.12 uses the python grpcio
module. Thus I need to build it in a venv, rather than relying on a
system package. There are a few things I'm not following, two small
issues that I can file PRs for, and one issue that I'm unclear on. I'm
using NetBSD 10 x86_64 with gcc 10 and python 3.13.

* No separate library and wrappers

It looks like the python wrapper does not depend on a C/C++ libgrpc, but
instead builds those files into the python module. That's not a
complaint, but I think it would be good to note that in the README, as
people may be expecting the "have a C lib, and then wrap it" idiom.

* Can't find tags

pypi has 1.76.0:
https://pypi.org/project/grpcio/1.76.0/

and it has a download link
https://files.pythonhosted.org/packages/b6/e0/318c1ce3ae5a17894d5791e87aea147587c9e702f24122cc7a5c8bbaeeb1/grpcio-1.76.0.tar.gz

which all seemed normal. I needed to modify sources to build because
of minor issues below, so "pip install" wasn't going to work. I found
the repo at https://github.com/grpc/grpc but I see no releases and no
tags.

How do I find the bits that correspond to pypi 1.76.0?
How was the tarball generated?

* latent_see.cc uses abs() without std::

As I understand it, compilers can resolve bare abs() in various ways,
including to the C99 standard library. The latent_see usage requires
the more expansive types in C++'s std::abs() and thus it should be
written that way. PR to follow; just mentioning it.

* lack of --std=c++17

The codebase needs c++17, but doesn't in general add --std=c++17 to
build lines. This causes failure with gcc 10, which doesn't default to
c++17 but supports it with --std=c++17.

I have a patch to add a netbsd stanza that adds --std; that's the
minimal change. PR to follow.

Alternatively, someone could add code that says "add --std=c++17
always", or maybe if !windows, an that would resolve the issue on all
platforms, but that's much harder to test and I don't want to jump in
with that as an outsider.

* conflicts with installed protobuf

pkgsrc has protobuf 33.1, which according to
https://github.com/protocolbuffers/protobuf is the current release.
Headers are installed in /usr/pkg/include.

Building grpc python (with python313 setup.py build), I find (with
interpolated -I flags probably from python-config) that the build reads
the package upb defs.inc instead of the one in third_party. The
versions are different and there's trouble in TSAN macros -- but
removing the package makes the build succeed. Clearly gprc-included upb
code and package upb headers don't go together.

It looks like the included version is upb 31.0, from the git logs.
I don't see a way to use system upb.
I don't see a plan to avoid upb headers that are at the same prefix as
python, yet this seems likely necessary for many.

Do others run into this?



* status

With the 2 patches above and the workaround of removing pkg protobuf,
the build completes. On to running tests, but that's promising.

Thanks,
Greg