Update migration path for py23 proposal #153
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mrovner
approved these changes
Jan 10, 2019
bazel-io
pushed a commit
to bazelbuild/bazel
that referenced
this pull request
Jan 14, 2019
This CL implements the bulk of the changes to the migration section of the design doc, described by PR bazelbuild/rules_python#153. A subsequent CL will do the flag rename from --experimental_better_python_version_mixing to --experimental_allow_python_version_transitions. The main changes in this CL are: 1. Instead of one experimental/incompatible flag, we have two: one for syntax and one for semantics. 2. The new API (--python_version flag and python_version attribute) is no longer guarded by an experimental flag, but rather is unconditionally available. 3. The old API (--force_python flag and default_python_version attribute) is now disabled by an experimental flag. (This was always the plan but this CL implements it.) The motivation for (1) is so that it's easier for users to migrate and easier for us to roll these changes out. It also simplifies some logic in PythonOptions.java and python_version.bzl, because the fallback from --python_version on to --force_python no longer cares about whether we're using the new or old semantics. The motivation for (2) is that the current logic for gating an attribute on an experimental/incompatible flag breaks native.existing_rules(). See #7071. In this case the experimental flag would have been very short-lived anyway, since we want these features to be migration ready by February. We still have to face #7071 before we can enable the incompatible change, but at least this CL unblocks further work without hacking up existing_rules() with ad hoc blacklists. Finally, I took this CL as an opportunity to downsize some of our shell integration tests by turning them into Java unit tests. This required updating the mocks a bit. Work towards #6583. RELNOTES: None PiperOrigin-RevId: 229261233
bazel-io
pushed a commit
to bazelbuild/bazel
that referenced
this pull request
Jan 15, 2019
As per bazelbuild/rules_python#153, this renames --experimental_better_python_version_mixing to --experimental_allow_python_version_transitions. Work towards #6583. RELNOTES: None PiperOrigin-RevId: 229274690
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This splits the syntactic and semantic changes into separate migration flags. The experimental flag for syntax is 100% backwards compatible.
This way, we can flip and eliminate both experimental flags before the incompatible changes are introduced. This allows us to do the incompatible change procedure in a single Bazel release cycle.