six is necessary for making these scripts cross compatible
between python 2.x and 3.x
Changes:
Add six to python_deps.include
Include python_deps.include to all Dockerfile templates in test directory
Include python_deps.include to all Dockerfile templates in stress_test directory
Include python_deps.include to all Dockerfile templates in interop_test directory
Replace print statements with print function calls (from futute..)
Replace .iteritems() with .items() wherever necessary
use six.moves to import BaseHTTPServer
Generate new dockerfiles using generate_projects.sh
Add dockerfile template for python_pyenv_x64 docker image
Generate the dockerfile using generate_projects.sh
Modify run_tests.py to include python3.5 and python3.6
Runs python_jessie_x64 for python versions 2.7 and 3.4, and
python_pyenv_x64 for python versions 3.5 and 3.6
The examples under <repo_root>/examples now rely on the released
versions. Those under src/objective-c/examples, as well as the tests,
rely on protoc and the plugin as compiled from head.
- Propagation of (rpc) method name.
- Invocation of the hook at (call, channel) x (creation, destruction)
- Added enum to identify the source of invocation.
- Fixed testing. Went from test fixture to simple test.
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.
This fixes Jenkins for that branch, as a backwards-incompatible change
was made in the script that runs the tests for all branches.
The lines added are exactly the same as those now in master, so that the
subsequent merge of 0.14 into master doesn’t conflict.