Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

incompatible_load_python_rules_from_bzl: Python rules now need to be loaded from @rules_python #9006

Open
brandjon opened this issue Jul 29, 2019 · 7 comments

Comments

@brandjon
Copy link
Member

commented Jul 29, 2019

Flag: --incompatible_load_python_rules_from_bzl
Available since: 0.29
Will be flipped in: 2.0
Feature tracking issue: #8893

Motivation

The "core" Python rule logic is currently bundled with Bazel as a combination of native symbols and symbols loaded from @bazel_tools//tools/python. Eventually the native rules will be ported to Starlark, and all symbols will live in bazelbuild/rules_python. In the meantime, we're making it so the user loads these symbols from the rules_python repository, even though they're largely still implemented inside of Bazel itself. This will help make future migration of rule logic to rules_python less painful.

Change

Enabling this flag causes the four native Python rules,

  • py_library
  • py_binary
  • py_test
  • py_runtime

to fail at analysis time when they are used directly instead of via rules_python.

Migration

Any usage of the these rules as a built-in symbol should be replaced with a use of the macros defined in rules_python as follows. (All four macros are defined in defs.bzl.)

# My BUILD file

py_binary(
    ...
)

should become

# My BUILD file

load("@rules_python//python:defs.bzl", "py_binary")

py_binary(
    ...
)

In the case of macros in .bzl files,

# My .bzl file

def my_macro(...):
    native.py_binary(
        ...
    )

should become

# My .bzl file

load("@rules_python//python:defs.bzl", "py_binary")

def my_macro(...):
    py_binary(
        ...
    )

To access the @rules_python repo you'll need to make sure you have the following in your WORKSPACE file:

# My WORKSPACE file

load("@bazel_tools//tools/build_defs/repo:git.bzl", "git_repository")

git_repository(
    name = "rules_python",
    remote = "https://github.com/bazelbuild/rules_python.git",
    commit = "4b84ad270387a7c439ebdccfd530e2339601ef27",  # (2019-08-02 or later)
)

load("@rules_python//python:repositories.bzl", "py_repositories")
py_repositories()

If you're using rules_python for pip support (which is separate from the core Python rules), you'll also need to call the pip_repositories() function.

Note that until recently, @rules_python went by the workspace name @io_bazel_rules_python. If you have a definition for the old name in your WORKSPACE file then you'll need to rename it, and ensure your commit is updated to a recent version.

@brandjon brandjon self-assigned this Jul 29, 2019

brandjon added a commit to brandjon/bazel that referenced this issue Jul 30, 2019
Add load() statements for Python rules in third_party
This replaces all direct uses of the native Python rules underneath the
third_party/ directory with load()s of the internal wrapper macros. These
macros are needed for compatibility with
`--incompatible_load_python_rules_from_bzl`.

Work toward bazelbuild#9006.

RELNOTES: None
brandjon added a commit to brandjon/bazel that referenced this issue Jul 31, 2019
Add load() statements for Python rules in third_party
This replaces all direct uses of the native Python rules underneath the
third_party/ directory with load()s of the internal wrapper macros. These
macros are needed for compatibility with
`--incompatible_load_python_rules_from_bzl`.

Work toward bazelbuild#9006.

RELNOTES: None
brandjon added a commit to brandjon/bazel that referenced this issue Jul 31, 2019
Add load() statements for Python rules in third_party
This replaces all direct uses of the native Python rules underneath the
third_party/ directory with load()s of the internal wrapper macros. These
macros are needed for compatibility with
`--incompatible_load_python_rules_from_bzl`.

Work toward bazelbuild#9006.

RELNOTES: None
bazel-io pushed a commit that referenced this issue Jul 31, 2019
Add internal macros and partially migrate Bazel for upcoming change
This adds `@bazel_tools//tools/python:private/defs.bzl`, which defines macro wrappers around the four native Python rules (`py_library`, `py_binary`, `py_test`, `py_runtime`). These wrappers simulate the behavior of `@rules_python//python:defs.bzl`, so that they are compatible with the upcoming `--incompatible_load_python_rules_from_bzl` flag.

This change also updates many direct uses of the native Python rules to use the wrappers instead. However, changes to the third_party/ directory have to be in a separate commit.

The new macros should only be used by Bazel itself. All external users should use @rules_python instead.

I'm omitting updating src/test/py/bazel/testdata/runfiles_test/*/BUILD.mock files because they appear to be tests that shouldn't complain until the flag is flipped, and I'm not sure that adding a load won't break them. Also not updating the examples/ dir for similar reasons.

Work toward #9006.

RELNOTES: None
PiperOrigin-RevId: 260858287
brandjon added a commit to brandjon/bazel that referenced this issue Jul 31, 2019
Add load() statements for Python rules in third_party
This replaces all direct uses of the native Python rules underneath the
third_party/ directory with load()s of the internal wrapper macros. These
macros are needed for compatibility with
`--incompatible_load_python_rules_from_bzl`.

Work toward bazelbuild#9006.

RELNOTES: None
brandjon added a commit to brandjon/bazel that referenced this issue Jul 31, 2019
Add load() statements for Python rules in third_party
This replaces all direct uses of the native Python rules underneath the
third_party/ directory with load()s of the internal wrapper macros. These
macros are needed for compatibility with
`--incompatible_load_python_rules_from_bzl`.

Work toward bazelbuild#9006.

RELNOTES: None
brandjon added a commit that referenced this issue Jul 31, 2019
Add load() statements for Python rules in third_party
This replaces all direct uses of the native Python rules underneath the
third_party/ directory with load()s of the internal wrapper macros. These
macros are needed for compatibility with
`--incompatible_load_python_rules_from_bzl`.

Work toward #9006.

RELNOTES: None
brandjon added a commit to brandjon/bazel that referenced this issue Aug 1, 2019
Add load() statements for Python rules in third_party
This replaces all direct uses of the native Python rules underneath the
third_party/ directory with load()s of the internal wrapper macros. These
macros are needed for compatibility with
`--incompatible_load_python_rules_from_bzl`.

Work toward bazelbuild#9006.

RELNOTES: None
brandjon added a commit to brandjon/bazel that referenced this issue Aug 1, 2019
Add load() statements for Python rules in third_party/
This replaces all direct uses of the native Python rules underneath the
third_party/ directory with load()s of the internal wrapper macros. These
macros are needed for compatibility with
`--incompatible_load_python_rules_from_bzl`.

Some of the uses are replaced by the file under the tools/ dir, which is
already used elsewhere in Bazel. A few uses have to use a new @rules_python
repo (see also bazelbuild#9029).

Work toward bazelbuild#9006.

RELNOTES: None
brandjon added a commit to brandjon/bazel that referenced this issue Aug 1, 2019
Add load() statements for Python rules in third_party/
This replaces all direct uses of the native Python rules underneath the
third_party/ directory with load()s of the internal wrapper macros. These
macros are needed for compatibility with
`--incompatible_load_python_rules_from_bzl`.

Some of the uses are replaced by the file under the tools/ dir, which is
already used elsewhere in Bazel. A few uses have to use a new @rules_python
repo (see also bazelbuild#9029).

Work toward bazelbuild#9006.

RELNOTES: None
brandjon added a commit to brandjon/bazel that referenced this issue Aug 1, 2019
Add load() statements for Python rules in third_party/
This replaces all direct uses of the native Python rules underneath the
third_party/ directory with load()s of the internal wrapper macros. These
macros are needed for compatibility with
`--incompatible_load_python_rules_from_bzl`.

Some of the uses are replaced by the file under the tools/ dir, which is
already used elsewhere in Bazel. A few uses have to use a new @rules_python
repo (see also bazelbuild#9029).

Work toward bazelbuild#9006.

RELNOTES: None
brandjon added a commit that referenced this issue Aug 1, 2019
Add load() statements for Python rules in third_party/
This replaces all direct uses of the native Python rules underneath the
third_party/ directory with load()s of the internal wrapper macros. These
macros are needed for compatibility with
`--incompatible_load_python_rules_from_bzl`.

Some of the uses are replaced by the file under the tools/ dir, which is
already used elsewhere in Bazel. A few uses have to use a new @rules_python
repo (see also #9029).

Work toward #9006.

RELNOTES: None
brandjon added a commit to brandjon/bazel that referenced this issue Aug 1, 2019
Add stub @rules_python to third_party/
This stub contains only one relevant file, @rules_python//python:defs.bzl,
which mimics the file at the same path in bazelbuild/rules_python. Having this
repo gives us a way to inject this defs.bzl file into our protobuf dependency,
which is loaded as a separate (local) external repo and therefore cannot access
the existing //tools/python:private/defs.bzl in Bazel's own workspace. It also
means we'll be compatible with the future upstream migration to fix protobuf
for bazelbuild#9006.

A separate PR will add this to the Bazel root WORKSPACE file (since
third_party/ must be updated in a separate commit).

Break-out of bazelbuild#9019. Work toward bazelbuild#9006.

RELNOTES: None
brandjon added a commit to brandjon/bazel that referenced this issue Aug 1, 2019
Add third_party/rules_python to WORKSPACE as @rules_python
These will be used by third_party/protobuf in a follow-up.

Also update a test that uses protobuf and that will break when protobuf is
updated (since the test can't be changed in the same PR as third_party/).

Break-out of bazelbuild#9019. Work toward bazelbuild#9006.

RELNOTES: None
brandjon added a commit that referenced this issue Aug 1, 2019
Add load() statements for Python rules in third_party/
This replaces all direct uses of the native Python rules underneath the
third_party/ directory with load()s of the internal wrapper macros. These
macros are needed for compatibility with
`--incompatible_load_python_rules_from_bzl`.

Some of the uses are replaced by the file under the tools/ dir, which is
already used elsewhere in Bazel. A few uses have to use a new @rules_python
repo (see also #9029).

Work toward #9006.

RELNOTES: None
bazel-io pushed a commit that referenced this issue Aug 1, 2019
Add stub @rules_python to third_party/
This stub contains only one relevant file, @rules_python//python:defs.bzl,
which mimics the file at the same path in bazelbuild/rules_python. Having this
repo gives us a way to inject this defs.bzl file into our protobuf dependency,
which is loaded as a separate (local) external repo and therefore cannot access
the existing //tools/python:private/defs.bzl in Bazel's own workspace. It also
means we'll be compatible with the future upstream migration to fix protobuf
for #9006.

A separate PR will add this to the Bazel root WORKSPACE file (since
third_party/ must be updated in a separate commit).

Break-out of #9019. Work toward #9006.

Closes #9044.

RELNOTES: None
brandjon added a commit to brandjon/bazel that referenced this issue Aug 1, 2019
Add third_party/rules_python to WORKSPACE as @rules_python
These will be used by third_party/protobuf in a follow-up.

Also update a test that uses protobuf and that will break when protobuf is
updated (since the test can't be changed in the same PR as third_party/).

Break-out of bazelbuild#9019. Work toward bazelbuild#9006.

RELNOTES: None
brandjon added a commit to brandjon/bazel that referenced this issue Aug 1, 2019
Add third_party/rules_python to WORKSPACE as @rules_python
These will be used by third_party/protobuf in a follow-up.

Also update a test that uses protobuf and that will break when protobuf is
updated (since the test can't be changed in the same PR as third_party/).

Break-out of bazelbuild#9019. Work toward bazelbuild#9006.

RELNOTES: None
brandjon added a commit to brandjon/bazel that referenced this issue Aug 1, 2019
Add load() statements for Python rules in third_party/
This replaces all direct uses of the native Python rules underneath the
third_party/ directory with load()s of the internal wrapper macros. These
macros are needed for compatibility with
`--incompatible_load_python_rules_from_bzl`.

Some of the uses are replaced by the file under the tools/ dir, which is
already used elsewhere in Bazel. A few uses have to use a new @rules_python
repo (see also bazelbuild#9029).

Work toward bazelbuild#9006.

RELNOTES: None
bazel-io pushed a commit that referenced this issue Aug 1, 2019
Add third_party/rules_python to WORKSPACE as @rules_python
These will be used by third_party/protobuf in a follow-up.

Also update a test that uses protobuf and that will break when protobuf is
updated (since the test can't be changed in the same PR as third_party/).

Break-out of #9019. Closes #9048. Work toward #9006.

RELNOTES: None
PiperOrigin-RevId: 261176215
brandjon added a commit to brandjon/bazel that referenced this issue Aug 1, 2019
Add load() statements for Python rules in third_party/
This replaces all direct uses of the native Python rules underneath the
third_party/ directory with load()s of the internal wrapper macros. These
macros are needed for compatibility with
`--incompatible_load_python_rules_from_bzl`.

Some of the uses are replaced by the file under the tools/ dir, which is
already used elsewhere in Bazel. A few uses have to use a new @rules_python
repo (see also bazelbuild#9029).

Work toward bazelbuild#9006.

RELNOTES: None
bazel-io pushed a commit that referenced this issue Aug 1, 2019
Add load() statements for Python rules in third_party/
This replaces all direct uses of the native Python rules underneath the
third_party/ directory with load()s of the internal wrapper macros. These
macros are needed for compatibility with
`--incompatible_load_python_rules_from_bzl`.

Some of the uses are replaced by the file under the tools/ dir, which is
already used elsewhere in Bazel. A few uses have to use a new @rules_python
repo (see also #9029).

Work toward #9006.

Closes #9019.

RELNOTES: None
brandjon added a commit to brandjon/subpar that referenced this issue Aug 2, 2019
Load Python rules from bazelbuild/rules_python
This migrates subpar for bazelbuild/bazel#9006. Note that it adds a dependency
on bazelbuild/rules_python, which means that these two repositories now have a
dependency cycle.

WORKSPACE and BUILD files in tests are also updated for the same.
brandjon added a commit to google/subpar that referenced this issue Aug 2, 2019
Load Python rules from bazelbuild/rules_python (#115)
This migrates subpar for bazelbuild/bazel#9006. Note that it adds a dependency
on bazelbuild/rules_python, which means that these two repositories now have a
dependency cycle.

WORKSPACE and BUILD files in tests are also updated for the same.
brandjon added a commit to brandjon/rules_python that referenced this issue Aug 2, 2019
Ensure all core Python rules are loaded from defs.bzl
This migrates rules_python itself for bazelbuild/bazel#9006. This entails
adding or updating load() statements to refer to //python:defs.bzl (not
//python:python.bzl), and updating whl.py so the generated repos refer to
@rules_python. Also updated the dependency on subpar for compatibility with
the flag. Par files are regenerated.
brandjon added a commit to bazelbuild/rules_python that referenced this issue Aug 2, 2019
Ensure all core Python rules are loaded from defs.bzl (#219)
This migrates rules_python itself for bazelbuild/bazel#9006. This entails
adding or updating load() statements to refer to //python:defs.bzl (not
//python:python.bzl), and updating whl.py so the generated repos refer to
@rules_python. Also updated the dependency on subpar for compatibility with
the flag. Par files are regenerated.
brandjon added a commit to brandjon/starlark that referenced this issue Aug 2, 2019
Load Python rules from @rules_python
This ensures compatibility with bazelbuild/bazel#9006.

Also add a basic .gitignore.
@brandjon

This comment has been minimized.

Copy link
Member Author

commented Aug 4, 2019

The downstream incompatible change pipeline won't test this until 0.29 is released, but in the meantime I did a custom downstream run with the flag flip here. Looks like several dozen failures, maybe almost half of all configurations in the pipeline.

@dslomov

This comment has been minimized.

Copy link
Contributor

commented Aug 5, 2019

Is there a tool to facilitate this migration? (it is a mechanic change, so buildifer should help)

@brandjon

This comment has been minimized.

Copy link
Member Author

commented Aug 5, 2019

Not at the moment, I'd like to add one but not sure how long that'll take. The changes amount to 1) adding WORKSPACE boilerplate, 2) adding load() statements to BUILD files, 3) (rarer) adding load() statements to .bzl files and replacing native.<py_rule> with <py_rule>.

@brandjon

This comment has been minimized.

Copy link
Member Author

commented Aug 5, 2019

Will be added by bazelbuild/buildtools#691. It doesn't currently do WORKSPACE files though -- looks like the java and cc bzl migrations don't do that either?

Yannic added a commit to Yannic/googletest that referenced this issue Aug 7, 2019
Prepare for Bazel incompatible changes
Fixes googletest for upcoming `--incompatible_load_cc_rules_from_bzl` (bazelbuild/bazel#8743) and `--incompatible_load_python_rules_from_bzl` (bazelbuild/bazel#9006).

This change was automatically generated with
buildifier -lint=fix -warnings=all $(find . -name "BUILD" -o -name "BUILD.bazel" -o -name "*.bzl")
Yannic added a commit to Yannic/googletest that referenced this issue Aug 7, 2019
Prepare for Bazel incompatible changes
Fixes googletest for upcoming `--incompatible_load_cc_rules_from_bzl` (bazelbuild/bazel#8743) and `--incompatible_load_python_rules_from_bzl` (bazelbuild/bazel#9006).

This change was automatically generated with `buildifier -lint=fix -warnings=all $(find . -name "BUILD" -o -name "BUILD.bazel" -o -name "*.bzl")`.
fweikert added a commit to fweikert/rules_python that referenced this issue Aug 7, 2019
Ensure all core Python rules are loaded from defs.bzl (bazelbuild#219)
This migrates rules_python itself for bazelbuild/bazel#9006. This entails
adding or updating load() statements to refer to //python:defs.bzl (not
//python:python.bzl), and updating whl.py so the generated repos refer to
@rules_python. Also updated the dependency on subpar for compatibility with
the flag. Par files are regenerated.
laurentlb added a commit to bazelbuild/starlark that referenced this issue Aug 9, 2019
Load Python rules from @rules_python (#79)
This ensures compatibility with bazelbuild/bazel#9006.

Also add a basic .gitignore.
@brandjon

This comment has been minimized.

Copy link
Member Author

commented Aug 20, 2019

Update: We will not be flipping this flag (or the analogous flags for java and cc) in Bazel 1.0. The main reasons are:

  • The blast radius is high. Pretty much every BUILD file in every project needs to be updated. There is tooling to do this automatically in buildifier, however...

  • The tooling does not yet automatically update WORKSPACE files. Users instead have to manually copy/paste the right incantation into their WORKSPACE from rules_python/java/cc's readme.md page. The Bazel federation is also not in a position to make this change easier yet.

  • The benefit is not large enough to overcome these issues. Although it's a step toward migrating the rules out of Bazel, as long as the actual rule implementations still live in Bazel we still have to support them for the duration of the 1.x development cycle.

With this in mind we'll look at targeting Bazel 2.0 instead. In the meantime we can improve tooling and add new flags for more related deprecations/migrations.

@aaliddell

This comment has been minimized.

Copy link
Contributor

commented Aug 20, 2019

What's the timescale on 2.0? It 'sounds' a long way off but that depends on the release cycle chosen for Bazel after 1.0.

Also, is the intention to replace the native implementations with the Starlark implementations (similar to @bazel_tools, but without the load) during the 1.0 lifetime, but not force the manual addition to workspace and load in BUILD until 2.0? That doesn't solve having to support both, but starts getting the Starlark implementations battle tested.

@brandjon

This comment has been minimized.

Copy link
Member Author

commented Aug 21, 2019

At this point the only thing set in stone about 2.0 is that it'll be at least 3 months.

Note that there is no Starlark implementation of the native Python rules -- only redirects in rules_python that export the native implementations as if they were defined in Starlark. Migrating the implementation to Starlark is not necessarily blocked on getting people to load from rules_python first. Only deleting/modifying the native rules is blocked on that.

bazel-io pushed a commit that referenced this issue Aug 28, 2019
Release 0.29.0 (2019-08-28)
Baseline: 6c5ef53

Cherry picks:

   + 338829f:
     Fix retrying of SocketTimeoutExceptions in HttpConnector
   + 14651cd:
     Fallback to next urls if download fails in HttpDownloader
   + b7d300c:
     Fix incorrect stdout/stderr in remote action cache. Fixes #9072
   + 9602176:
     Automated rollback of commit
     0f0a0d5.
   + da557f9:
     Windows: fix "bazel run" argument quoting
   + ef8b6f6:
     Return JavaInfo from java proto aspects.
   + 209175f:
     Revert back to the old behavior of not creating a proto source
     root for generated .proto files.
   + 644060b:
     Fix PatchUtil for parsing special patch format
   + 067040d:
     Put the removal of the legacy repository-relative proto path
     behind the --incompatible_generated_protos_in_virtual_imports
     flag.
   + 76ed014:
     repository mapping lookup: convert to canonical name first

Important changes:

  - rule_test: fix Bazel 0.27 regression ("tags" attribute was
    ingored, #8723
  - Adds --incompatible_enable_execution_transition, which enables
    incremental migration of host attributes to exec attributes.
  - objc_proto_library rule has been deleted from Bazel.
  - repository_ctx.read is no longer restricted to files
        in the repository contructed.
  - tags 'no-remote', 'no-cache', 'no-remote-cache',
    'no-remote-exec', 'no-sandbox' are propagated now to the actions
    from targets when '--ncompatible_allow_tags_propagation' flag set
    to true. See #8830.
  - Adds flag
    --//tools/build_defs/pkg:incompatible_no_build_defs_pkg. This
    flag turns off the rules //tools/build_defs/pkg:{pkg_deb,
    pkg_rpm, pkg_tar}.
  - The Android NDK is now integrated with toolchains. To use them,
    pass the `--extra_toolchains=@androidndk//:all` flag or register
    them in your WORKSPACE with
    `register_toolchains("@androidndk//:all")`.
  - Stdout and stderr are checked to determine if output is going to a
    terminal. `--is_stderr_atty` is deprecated and `--isatty` is
    undeprecated.
  - --incompatible_load_proto_rules_from_bzl was added to forbid
    loading the native proto rules directly. See more on tracking
    issue #8922
  - Docker Sandbox now respects remote_default_platform_properties
  - pkg_deb, pkg_rpm & pkg_tar deprecation plan announced in the
    documentation.
  - The new java_tools release:
    * fixes #8614
    * exposes a new toolchain `@java_tools//:prebuilt_toolchain`
    which is using all the pre-built tools, including singlejar and
    ijar, even on remote execution. This toolchain should be used
    only when host and execution platform are the same, otherwise the
    binaries will not work on the execution platform.
  - java_common.compile supports specifying
    annotation_processor_additional_inputs and
    annotation_processor_additional_outputs for the Java compilation
    action for supporting annotation processors that consume or
    produce artifacts. Fixes #6415
  - There is now documentation on optimizing Android app build
    performance. Read it at
    https://docs.bazel.build/versions/0.29.0/android-build-performance
    .html
  - Execution log now respects --remote_default_platform_properties
  - Include a link to the relevant documenation on transitive Python
    version errors.
  - New incompatible flag
    --incompatible_disable_target_provider_fields removes the ability
    (in Starlark) to access a target's providers via the field syntax
    (for example, `ctx.attr.dep.my_provider`). The provider-key
    syntax should be used instead (for example,
    `ctx.attr.dep[MyProvider]`). See
    #9014 for details.
  - A new platform exec_properties is added to replace
    remote_execution_properties.
  - Added --incompatible_load_python_rules_from_bzl, which will be
    flipped in Bazel 1.0. See
    #9006.
  - add --break_build_on_parallel_dex2oat_failure to shortcut tests
    on dex2oat errors

This release contains contributions from many people at Google, as well as Alexander Ilyin, Arek Sredzki, Artem Zinnatullin, Benjamin Peterson, Fan Wu, John Millikin, Loo Rong Jie, Marwan Tammam, Oscar Bonilla, Peter Mounce, Sergio Rodriguez Orellana, Takeo Sawada, and Yannic Bonenberger.
buchgr pushed a commit to buchgr/bazel that referenced this issue Aug 30, 2019
Release 0.29.0 (2019-08-28)
Baseline: 6c5ef53

Cherry picks:

   + 338829f:
     Fix retrying of SocketTimeoutExceptions in HttpConnector
   + 14651cd:
     Fallback to next urls if download fails in HttpDownloader
   + b7d300c:
     Fix incorrect stdout/stderr in remote action cache. Fixes bazelbuild#9072
   + 9602176:
     Automated rollback of commit
     0f0a0d5.
   + da557f9:
     Windows: fix "bazel run" argument quoting
   + ef8b6f6:
     Return JavaInfo from java proto aspects.
   + 209175f:
     Revert back to the old behavior of not creating a proto source
     root for generated .proto files.
   + 644060b:
     Fix PatchUtil for parsing special patch format
   + 067040d:
     Put the removal of the legacy repository-relative proto path
     behind the --incompatible_generated_protos_in_virtual_imports
     flag.
   + 76ed014:
     repository mapping lookup: convert to canonical name first

Important changes:

  - rule_test: fix Bazel 0.27 regression ("tags" attribute was
    ingored, bazelbuild#8723
  - Adds --incompatible_enable_execution_transition, which enables
    incremental migration of host attributes to exec attributes.
  - objc_proto_library rule has been deleted from Bazel.
  - repository_ctx.read is no longer restricted to files
        in the repository contructed.
  - tags 'no-remote', 'no-cache', 'no-remote-cache',
    'no-remote-exec', 'no-sandbox' are propagated now to the actions
    from targets when '--ncompatible_allow_tags_propagation' flag set
    to true. See bazelbuild#8830.
  - Adds flag
    --//tools/build_defs/pkg:incompatible_no_build_defs_pkg. This
    flag turns off the rules //tools/build_defs/pkg:{pkg_deb,
    pkg_rpm, pkg_tar}.
  - The Android NDK is now integrated with toolchains. To use them,
    pass the `--extra_toolchains=@androidndk//:all` flag or register
    them in your WORKSPACE with
    `register_toolchains("@androidndk//:all")`.
  - Stdout and stderr are checked to determine if output is going to a
    terminal. `--is_stderr_atty` is deprecated and `--isatty` is
    undeprecated.
  - --incompatible_load_proto_rules_from_bzl was added to forbid
    loading the native proto rules directly. See more on tracking
    issue bazelbuild#8922
  - Docker Sandbox now respects remote_default_platform_properties
  - pkg_deb, pkg_rpm & pkg_tar deprecation plan announced in the
    documentation.
  - The new java_tools release:
    * fixes bazelbuild#8614
    * exposes a new toolchain `@java_tools//:prebuilt_toolchain`
    which is using all the pre-built tools, including singlejar and
    ijar, even on remote execution. This toolchain should be used
    only when host and execution platform are the same, otherwise the
    binaries will not work on the execution platform.
  - java_common.compile supports specifying
    annotation_processor_additional_inputs and
    annotation_processor_additional_outputs for the Java compilation
    action for supporting annotation processors that consume or
    produce artifacts. Fixes bazelbuild#6415
  - There is now documentation on optimizing Android app build
    performance. Read it at
    https://docs.bazel.build/versions/0.29.0/android-build-performance
    .html
  - Execution log now respects --remote_default_platform_properties
  - Include a link to the relevant documenation on transitive Python
    version errors.
  - New incompatible flag
    --incompatible_disable_target_provider_fields removes the ability
    (in Starlark) to access a target's providers via the field syntax
    (for example, `ctx.attr.dep.my_provider`). The provider-key
    syntax should be used instead (for example,
    `ctx.attr.dep[MyProvider]`). See
    bazelbuild#9014 for details.
  - A new platform exec_properties is added to replace
    remote_execution_properties.
  - Added --incompatible_load_python_rules_from_bzl, which will be
    flipped in Bazel 1.0. See
    bazelbuild#9006.
  - add --break_build_on_parallel_dex2oat_failure to shortcut tests
    on dex2oat errors

This release contains contributions from many people at Google, as well as Alexander Ilyin, Arek Sredzki, Artem Zinnatullin, Benjamin Peterson, Fan Wu, John Millikin, Loo Rong Jie, Marwan Tammam, Oscar Bonilla, Peter Mounce, Sergio Rodriguez Orellana, Takeo Sawada, and Yannic Bonenberger.
@guibou guibou referenced this issue Sep 3, 2019
3 of 10 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.