Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
incompatible_load_python_rules_from_bzl: Python rules now need to be loaded from @rules_python #9006
The "core" Python rule logic is currently bundled with Bazel as a combination of native symbols and symbols loaded from
Enabling this flag causes the four native Python rules,
to fail at analysis time when they are used directly instead of via rules_python.
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
# My BUILD file py_binary( ... )
# 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( ... )
# My .bzl file load("@rules_python//python:defs.bzl", "py_binary") def my_macro(...): py_binary( ... )
To access the
# 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
Note that until recently,
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
Update: We will not be flipping this flag (or the analogous flags for java and cc) in Bazel 1.0. The main reasons are:
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.
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
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.