fix: use runfiles symlinks for venv symlink creation to reduce action count

[rickeylev]

When the venv files are materialized, it can result in many symlink actions
being created. Rather than register them as regular symlink actions, batch them
into the runfiles object, which can probably handle large numbers of them more
efficiently.

Work towards #3401

[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 addresses a performance bottleneck in Bazel builds related to Python virtual environment (venv) creation. It optimizes the process of materializing venv files by consolidating numerous individual symlink actions into a more efficient runfiles mechanism. This change aims to reduce the total number of actions Bazel needs to perform, leading to faster and more streamlined builds, particularly for projects with extensive Python dependencies.

Highlights

• Performance Optimization: The pull request introduces a significant performance improvement by changing how virtual environment (venv) symlinks are created. Instead of generating many individual symlink actions, they are now batched into a runfiles object, which is expected to reduce the overall action count in Bazel builds.
• Refactored Venv Symlink Handling: The create_venv_app_files function has been refactored to return a structured object containing both direct venv files and a map of symlinks specifically intended for runfiles. This separation allows for more efficient processing of file-based symlinks.
• Integration with Executable Creation: The _create_venv function now consumes the newly structured output from create_venv_app_files, specifically utilizing the runfiles_symlinks to merge them into the executable's runfiles, ensuring all necessary dependencies are correctly linked for runtime.

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 is a good optimization that refactors venv symlink creation to use runfiles symlinks, which should improve performance by reducing the number of individual actions. The implementation appears correct and aligns with the stated goal. I have provided a few suggestions to improve code clarity, documentation, and to remove an unused import.

[rickeylev]

As an example: When depending on torch, it reduces the number of actions by about
10,000.

bazel aquery --output=summary //docs:sphinx-build before/after when torch is added as a dep

Prior to this change:

Action	Before	After
Symlink	12,163	0
RawSymlink	98	98
Total actions	12273	110

(I omitted action counts that were the same)

Build might be better, but it's hard to tell (initially it seemed like before was half a second slower, but after re-running both many times, the two seem to be converging in how long they take; this is probably more sensitive to the particulars of how the two methods create the files on disk)