* Expose the C-Core API in Cython layer
* Handle the object translation
* Create a separate package for Channelz specifically
* Handle nullptr and raise exception if seen one
* Translate C++ Channelz unit tests
* Adding 5 more invalid query unit tests
Adding peripheral utility for grpcio-channelz package
* Add to `pylint_code.sh`
* Add to Python build script
* Add to artifact build script
* Add to Bazel
* Add to Sphinx module list
See https://github.com/grpc/grpc/issues/15253 for more context. The
original behavior when running Python tests is to try to create a
virtual env with the specifed Python version. If there is an issue
with that, fallback to the system's default Python version. This leads to
misleading test results, so removing the fallback and failing the test
when virtual env fails to instantiate the specified Python version is
the new behavior.
With the upgrade of Kokoro macOS workers to Sierra, not all versions of
Python have a pip version new enough to have TLSv1.2. This change should
make macOS Python testing more resilient to environment changes.
Fix for issue #14815. Pinning to 9.0.3 doesn't work because pip fails to
recognize that as a valid version. Newer versions of pip have a fallback
on macOS to use SecureTransport instead of their outdated OpenSSL that
doesn't support TLSv1.2.
Fix for issue #14815. Pinning to 9.0.3 doesn't work because pip fails to
recognize that as a valid version. Newer versions of pip have a fallback
on macOS to use SecureTransport instead of their outdated OpenSSL that
doesn't support TLSv1.2.
Pip refuses to recognize the presence of existent installations for some
reason and decides to download from PyPI instead of using what's already
installed as dependencies for our distributions-under-test. This forces
pip to respect our wishes at the cost of some verbosity.
Removes MinGW flags from various build scripts, since they're now set in
our `setup.py`s by default. Also removes the arguments for the
extensions in grpcio's setup.py; that function was already accessing
globals anyway, might as well go whole-hog.
Before this change, running Python tests individually required
building a tox environment via the run_tests script and then specifying
long environment variables to filter out just the test we wanted to run
(and then we wouldn't be able to get the output on interrupt, nor would
we have an easy way of determining the PID of the process for debugger
attachment). Now invoking the build_python.sh script creates a workable
python virtual environment that includes all necessary libraries and
tests (s.t. running a single test is now possible by just knowing the
module name). This does not change existing supported means of running
tests (e.g. through run_tests.py).
An additional way of running individual tests has been introduced.
Following invocation of `./tools/run_tests/build_python.sh` (or
run_tests.py), one may invoke
./$VENV/bin/python -m $TEST_MODULE_NAME
and acquire a single running process that *is* the test process (rather
than a parent of the process). $VENV is the virtual environment name
specified to `build_python.sh` (defaults to `py27`) and
$TEST_MODULE_NAME is what it says on the tin.