feat: basic build data with stamping

[rickeylev]

This makes build data accessible to binaries. By default, some basic information
is always available: target name, config mode, config id, and if stamping was enabled.

When --stamp is enabled, the full workspace_status_command output is included in the
build information.

Build information is made available through a special bazel_binary_info module. This
module is created by the bootstrap and injected into sys.modules. It provides an API
for gettting the raw build information that was written. Exposing a module, instead
of a file, is done insulate from the Bazel-ism of runfiles.

When stamping is enabled, the way stamped data works is a bit round about to get
the desired semantics: that the build data reflects the most recent build of a
binary, not the last cached value of the build information (e.g., if I build
a binary, then modify a file in the binary, then build again, the build data
should reflect the timestamp of the second build). Normal Bazel caching, however,
makes that somewhat difficult (the build data file has to take the full transitive
set of files as inputs to properly detect changes, otherwise it'll get cached
on first build of the binary; plus actions can't take runfiles objects as inputs).

To work around this, we use some special APIs to get ctx.version_file information
into the output without entirely destroying caching.

• Because ctx.version_file doesn't trigger cache invalidation, a special helper,
  py_internal.copy_without_caching(), is used to make it always invalidate
  caching. Now we can ensure we have a copy of the most recent invocation data.
• To prevent the above from always rebuilding a binary, another special api,
  py_internal.declare_constant_metadata_file() is used to restore the behavior
  of a file never invalidating caching (even if it changes).

This dance is necessary because actions can't take runfiles as direct inputs. It
also avoids having to pass the entire program's transitive set of files as an input
just to do input change tracking.

Note the above only applies when stamping is enabled. Unstamped binaries don't
do any of this.

Along the way...

• The stamp attribute now transitions the --stamp flag. This was necessary so that
  the dependency on version_info was conditional on stamping.
• Remove a defunct helper from the stage2 bootstrap code.

[gemini-code-assist]

Summary of Changes

Hello @rickeylev, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces the capability for Python binaries to access their build-time information, such as target name, config mode, and stamping status. It establishes a new bazel_binary_info module for this purpose and integrates Bazel's --stamp flag to include detailed workspace status information when enabled. A significant portion of the changes addresses the intricate challenges of Bazel's caching mechanisms to ensure that stamped build data is always up-to-date without excessively impacting build performance.

Highlights

• Build Data Exposure: Python binaries can now access build-time information via a new bazel_binary_info module, providing details like target name, config mode, and stamping status.
• Stamping Integration: When the --stamp flag is enabled, the output of Bazel's workspace_status_command is included in the build data, offering more detailed build information.
• Caching Workaround for Stamping: A sophisticated mechanism, utilizing py_internal.copy_without_caching and py_internal.declare_constant_metadata_file, ensures that stamped build data always reflects the most recent build without negatively impacting Bazel's caching for other parts of the binary.
• stamp Attribute Transition: The stamp attribute in py_binary and py_test rules now correctly transitions the Bazel --stamp flag, making the stamping behavior conditional on this attribute.
• Exec Configuration Exemption: Stamping is explicitly disabled for the exec configuration to prevent unnecessary cache invalidation when building tools.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a valuable feature for embedding build information into Python binaries. The implementation is well-designed, particularly the clever handling of Bazel's caching mechanisms to ensure stamped data is always fresh without destroying cacheability for dependent actions. The introduction of the bazel_binary_info module provides a clean and user-friendly API for accessing this data. The code is well-structured and includes thorough tests. I have a couple of suggestions for minor improvements to enhance efficiency and maintainability.

[aignas]

LGTM, this is a great feature!

[aignas]

We could also tell, that if users want, the could, for example set the __version__ or other standard Python metadata from the bazel_binary_info module. What do you think?