refactor: avoid conflict merging when shared libraries are present (#3448)

Today, when a shared library is present, an extra VenvSymlinkEntry is
generated so that
it is linked directly. Unfortunately, this will always have a path
overlap conflict with
the rest of the venv symlinks, which triggers the conflict merge logic
later in
py_executable. That logic is expensive, as it must flatten all the files
and then
link each file individually (essentially doubling the number of files
materialized).
For large packages like torch (10k+ files), this can dramatically
increase overhead.

To fix, generate VenvSymlinkEntries that don't overlap. The basic logic
for how this works
is to identify paths that *must* be directly linked, marking all their
parent directories
as not being able to be directly linked, and then grouping what remains
into the highest
directly-linkable path.

Along the way, drop the logic that only considers code files and special
cases `__init__.py`
files and implicit packages. This is simplify the code and more
correctly map the
extracted wheel into the venv.
2 files changed
tree: ac20ee5d15bacea37e915522f202ee09c75a13f2
  1. .bazelci/
  2. .bcr/
  3. .ci/
  4. .github/
  5. docs/
  6. examples/
  7. gazelle/
  8. private/
  9. python/
  10. sphinxdocs/
  11. tests/
  12. tools/
  13. .bazelignore
  14. .bazelrc
  15. .bazelrc.deleted_packages
  16. .bazelversion
  17. .editorconfig
  18. .git-blame-ignore-revs
  19. .gitattributes
  20. .gitignore
  21. .pre-commit-config.yaml
  22. .python-version
  23. .readthedocs.yml
  24. addlicense.sh
  25. AGENTS.md
  26. AUTHORS
  27. BUILD.bazel
  28. BZLMOD_SUPPORT.md
  29. CHANGELOG.md
  30. CONTRIBUTING.md
  31. CONTRIBUTORS
  32. GEMINI.md
  33. internal_dev_deps.bzl
  34. internal_dev_setup.bzl
  35. LICENSE
  36. MODULE.bazel
  37. README.md
  38. RELEASING.md
  39. version.bzl
  40. WORKSPACE
  41. WORKSPACE.bzlmod
README.md

Python Rules for Bazel

Build status

Overview

This repository is the home of the core Python rules -- py_library, py_binary, py_test, py_proto_library, and related symbols that provide the basis for Python support in Bazel. It also contains package installation rules for integrating with PyPI and other indices.

Documentation for rules_python is at https://rules-python.readthedocs.io and in the Bazel Build Encyclopedia.

Examples live in the examples directory.

The core rules are stable. Their implementation is subject to Bazel's backward compatibility policy. This repository aims to follow semantic versioning.

The Bazel community maintains this repository. Neither Google nor the Bazel team provides support for the code. However, this repository is part of the test suite used to vet new Bazel releases. See How to contribute page for information on our development workflow.

Documentation

For detailed documentation, see https://rules-python.readthedocs.io

Bzlmod support

See Bzlmod support for more details.