Description
At runtime, it can be useful to know what various information was at build time. information such as:
- Bazel-wide information such as timestamps, VCS ids, etc (ctx.version_file, ctx.info_file)
- Current build config information (python version, cpu, gpu, etc)
- Target/binary specific information (target name, attribute values, etc)
I think that comprises the various build meta-data things.
Note that the current build config information isn't global -- transition can affect settings. This means two binaries in the same build invocation could have different config states, which means, however they store those values, those values can't be store into a file at the same location in runfiles.
Implementation wise, I'm thinking the following:
For Bazel wide information, we copy ctx.version_file and ctx.info_file to a well know location in runfiles using runfiles.root_symlinks. These are only copied over if stamping is enabled. I'm thinking bazel_build_info/{volatile,stable}.txt (version_file and info_file, respectively). Access to this data is done via the Python module rules_python.build_info.bazel_info, which is largely simple getters for the raw values in the files. Maybe some convenience functions for e.g. well known keys.
For current build config and target/binary-specific information, it's a bit more complicated, but works similarly. This info is still written to a file, but the name is based on the target name, e.g. _{bin_name}_build_config.json). The file content is a json object of various information e.g. target name, embed_label, etc. This data is only written if stamping is enabled.
The bootstrap then has 2 pieces of information added to it: the target name and the path to the build config info file. These are written into the stage2 bootstrap py code. The stage2 bootstrap then creates a module, _rules_python_binary_info with these two constants and puts it in sys.modules. Access to this data is done via the Python module rules_python.build_info.binary_info. Under the hood, it uses _rules_python_binary_info to locate the files and provides accessors to it. Stated another way, the location and format of the data file is an implementation detail.
So that's the gist.
Further thoughts / open questions
Something I'm not sure what to do with is if something is run using sys.executable. Letting those programs inspect the bazel info seems useful. However, they don't go through the stage1 or stage2 bootstrap, so can't get the target name. Putting the target name in e.g. bazel_site_init seems weird. I like the idea of the "bazel logic specific to venv site setup" being agnostic to a binary (i.e. allowing two binaries to use the same venv). But, i think this could be dealt with later.