Improve python shell integration test coverage #6868
Labels
P4
This is either out of scope or we don't have bandwidth to review a PR. (No assignee)
stale
Issues or PRs that are stale (no activity for 30 days)
team-Rules-Python
Native rules for Python
type: process
Comments
brandjon
added
P3
bazel-io
pushed a commit
that referenced
this issue
Dec 14, 2018
871cd6f added some non-determinism to how the WORKSPACE file is initialized. This was partially addressed in a7773b4. The current CL cleans up an additional source of non-determinism, and factors bazel_skylib setup into a separate helper for better granularity. It also modifies the workspace reinitialization added to test suites by 871cd6f to instead just call the skylib setup. To avoid a situation where test suite set_up/tear_down overrides testenv's set_up/tear_down, the latter's functions have been renamed to testenv_set_up and testenv_tear_down. Factored some tests to use $WORKSPACE_NAME instead of inlining its assumed value. Resorted to some sed hackery to substitute this var in long here-docs -- I figured this was preferable to either hardcoding the name in the here-doc, or escaping a bunch of other unrelated substitutions. Cleanup work toward #6868. RELNOTES: None PiperOrigin-RevId: 225618009
bazel-io
pushed a commit
that referenced
this issue
Dec 17, 2018
OSS a Python version test. This uses a `use_fake_python_runtimes` shell setup helper for creating a standard fake Python environment. Also add tests that the system Python interpreters can be used to run py_binary targets, and that runfiles are accessible. These currently do not run on our Mac or Windows workers. Fixed a bug in how the stub template gets the interpreter path, where relative paths with slashes weren't recognized on Windows. Also made it tolerate .cmd and .bat as valid extensions of the python "runtime" (in actuality for these tests, a wrapper). Work toward #6868 and #6583. RELNOTES: None PiperOrigin-RevId: 225876746
|
Also note that some of the test coverage just added above is not yet enabled on our CI for Mac and Windows. |
bazel-io
pushed a commit
that referenced
this issue
Dec 18, 2018
Clients that care about the Python version mode should use getters/setters that respect `--experimental_better_python_version_mixing`. This ensures that the correct field is updated and the correct transition semantics are used. select()s that examine "force_python" will still see the raw value of that flag. For partial compatibility we still update this flag when transitioning the Python version, but targets that are not underneath py_binary/py_test targets may still observe "force_python" values that are inconsistent with the actual Python mode. The future fix will be to use a new feature flag instead of any native flag. Work toward #6583, #6868. Design doc for new semantics here: https://github.com/bazelbuild/rules_python/blob/master/proposals/2018-10-25-selecting-between-python-2-and-3.md RELNOTES: None PiperOrigin-RevId: 226043392
|
From #3567: Make sure to include coverage for end-to-end behavior of builds using in-build (hermetic) Python runtimes. |
lberki
added
P4
|
Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Namely, OSS some internal-only basic "hello world" tests demonstrating py_binary, py_library, runfiles access, and choosing the Python version.
The text was updated successfully, but these errors were encountered: