Now the grpc_2_0 flag is no longer required for the only-generate-code-
elements-in-_pb2_grpc.py-files behavior and the grpc_1_0 flag is
required for the add-generated-gRPC-using-code-elements-to-_pb2.py-
files behavior.
Beta code elements are not generated at all in _pb2_grpc.py files.
This duplicates a lot of the in-test code generation done in
_split_definitions_test. In a future clean-up we may want to
deduplicate the common behavior, put it in a module available to all
other tests, and do all of our testing of generated code with in-test
code generation.
I made this mistake in 2010985ab2 but
only with yesterday's release of six 1.11.0 has it started failing
("TypeError: metaclass conflict: the metaclassof a derived class must
be a (non-strict) subclass of the metaclasses of all its bases").
We were mistaken before when we were testing _pb2.py files being
generated in one directory and _pb2_grpc.py files being generated in
another directory. Sure, that was a thing our code generator could do,
but because of the way paths and packages work in Python it wasn't a
realistic use case for actual users.
This test now tests _pb2.py files and _pb2_grpc.py files being
generated either together or independently of one another, and if
independently, in either order. Looking forward to an eventual
py_grpc_library Bazel rule, that's what actually matters.
- Move it out of the "unit" package, as it's not itself a unit test.
- Suffix the test class with "Test" as we do with every other subclass
of unittest.TestCase.
- Add a larger-than-we'll-need-any-time-soon maxDiff so that failures
are fully described.
- Relax the assertion from assertListEqual to assertSequenceEqual
since we don't actually care whether or not the sequences being
compared are list instances.
- Change the order of the assertions arguments to match the
"<expected>, <actual>" convention used in our assert*Equal calls
elsewhere throughout the test corpus.
- Internal implementation simplifications.
Were this not done these would break when the default behavior of gRPC
Python Protoc Plug-In is changed to be the put-gRPC-code-elements-only-
in-_pb2_grpc.py-files behavior that currently happens only when the
grpc_2_0 flag is passed.
We'll soon be flipping the default behavior of gRPC Python Protoc
Plug-In to the later-than-gRPC-1.0 "code elements only in a
separate _pb2_grpc.py file and no Beta-API-using generated code
elements" behavior; this flag will be the supported (supported for a
while, though not exactly sure how long) means of using the older
"also put gRPC-using code elements in the generated _pb2.py file"
behavior that has been in place since gRPC 1.0.
Yuchen Zeng
Nathaniel Manista
Alexander Polcyn
David Garcia Quintas
Sree Kuchibhotla
Yash Tibrewal
ncteisen
Muxi Yan
Craig Tiller
Justin Burke
Vijay Pai
Ken Payson
ZhouyihaiDing
jiangtaoli2016
Jan Tattermusch