native.bazel_version is not available for macros or rules

Description of the problem / feature request:

I would like access to native.bazel_version from BUILD macros and rules. It appears that native.bazel_version only works from WORKSPACE macros (as tested here).

This also means that versions.bzl from bazel-skylib only works from WORKSPACE files. This is very surprising and appears to be an undocumented limitation. If you try to invoke it from a BUILD file you get:

ERROR: /usr/local/google/home/haberman/.cache/bazel/_bazel_haberman/17449526a2508fe9f4def2619c761b7e/external/com_google_protobuf/BUILD:284:2: in //:build_defs.bzl%_upb_proto_libra
ry_aspect aspect on proto_library rule @com_google_protobuf//:field_mask_proto:
Traceback (most recent call last):                                                                                                                                                 
        File "/usr/local/google/home/haberman/.cache/bazel/_bazel_haberman/17449526a2508fe9f4def2619c761b7e/external/com_google_protobuf/BUILD", line 284
                //:build_defs.bzl%_upb_proto_library_aspect(...)                                                                                                                   
        File "/usr/local/google/home/haberman/code/upb/build_defs.bzl", line 383, in _upb_proto_aspect_impl
                cc_library_func(ctx = ctx, name = ctx.rule.attr.na..., <3 more arguments>)
        File "/usr/local/google/home/haberman/code/upb/build_defs.bzl", line 287, in cc_library_func
                versions.get()                                                                                                                                                      
        File "/usr/local/google/home/haberman/.cache/bazel/_bazel_haberman/17449526a2508fe9f4def2619c761b7e/external/bazel_skylib/lib/versions.bzl", line 20, in versions.get       
                native.bazel_version                                                                                                                                                
no native function or rule 'bazel_version'  

It took a lot of searching to figure out the reason for this error: versions.bzl only works from WORKSPACE files.

Since the native module is only available during loading (not analysis), it might be better to have a separate module for bazel_version that is available during both loading and analysis. Then bazel-skylib’s versions.bzl could use that. That way it could work from any context.

Feature requests: what underlying problem are you trying to solve with this feature?

My project only works with certain versions of Bazel. I would like to warn users if they are building my project with an unsupported Bazel version, and tell them what the supported versions are.

Also, supporting older Bazel versions sometimes requires legacy fallback code. I would like to be able to switch out different logic based on the Bazel version.

What operating system are you running Bazel on?

Linux and macOS.

What’s the output of bazel info release?

I’m currently supporting Bazel 0.24.1 and 0.25.2.

Have you found anything relevant by searching the web?

I discovered that native.bazel_version is tested, but only from WORKSPACE files: https://github.com/bazelbuild/bazel/blob/master/src/test/shell/bazel/skylark_repository_test.sh#L1159-L1199

I also discovered that native.bazel_version has never actually been documented in https://docs.bazel.build/versions/master/skylark/lib/native.html, despite the fact it is used from bazel-skylib.

[keith]

Another +1 for this, we had a place where we wanted this because bazel broke support for an API between the LTS version and HEAD, and as rules authors we wanted to continue supporting both for our users, I came up with a huge hack instead. https://github.com/bazelbuild/bazel/issues/14996

[Wyverald]

I see. I think it might be more prudent to offer some sort of general feature detection API, as opposed to a version string check. I’d say this is slightly higher than P4, but the Starlark team might not have the bandwidth unfortunately.