Currently we don't check generated python proto files in source control, instead they're generated during build by setuptools. We've had problems lately because of this as this process means we need to manage additional "setup requirements" and protobuf versions don't always play well with one another.
We also distribute python library as a wheel with generated proto files inside, so keeping these files out of source control doesn't give us any benefit in terms of client system compatibility. protobuf version used is still determined on our ci servers during build-time.
Another major con of running protoc during build-time is that we won't be able to get rid of setup.py file even after a migration to pyproject.toml.
I propose to instead add a new target in Makefile that will generate proto files and will be independent of setuptools. The generated files will be commited to the source control. We can also add a test in ci that will check that proto definitions and generated code is consistent with one another.
Currently we don't check generated python proto files in source control, instead they're generated during build by setuptools. We've had problems lately because of this as this process means we need to manage additional "setup requirements" and protobuf versions don't always play well with one another.
We also distribute python library as a wheel with generated proto files inside, so keeping these files out of source control doesn't give us any benefit in terms of client system compatibility. protobuf version used is still determined on our ci servers during build-time.
Another major con of running protoc during build-time is that we won't be able to get rid of
setup.pyfile even after a migration topyproject.toml.I propose to instead add a new target in
Makefilethat will generate proto files and will be independent of setuptools. The generated files will be commited to the source control. We can also add a test in ci that will check that proto definitions and generated code is consistent with one another.