feat(pypi): generate filegroup with all extracted wheel files (#3011)

Adds a filegroup with all the files that came from the extracted wheel.

This has two benefits over using `whl_filegroup`: it avoids copying the
wheel
and makes the set of files directly visible to the analysis phase.

Some wheels are multiple gigabytes in size (e.g. torch, cuda,
tensorflow), so
avoiding the copy and archive processing saves a decent amount of time.

Knowing the specific files at analysis time is generally beneficial. The
particular case I ran into was the CC rules were unhappy with a
TreeArtifact
of header files because they couldn't enforce some check about who was
properly providing headers that were included (layering check?).

Another example is using the unused_inputs_list optimization, which
allows
an action to ignore inputs that aren't actually used. e.g. an action
could
take all the wheel's files as inputs, only care about the headers, and
then
tell bazel all the non-header files aren't relevant, and thus changes to
other files don't re-run the thing that only cares about headers.

---------

Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com>
9 files changed
tree: cd783708262324843d8304b4335d463943c05e18
  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. .bazelversion
  16. .editorconfig
  17. .git-blame-ignore-revs
  18. .gitattributes
  19. .gitignore
  20. .pre-commit-config.yaml
  21. .python-version
  22. .readthedocs.yml
  23. addlicense.sh
  24. AUTHORS
  25. BUILD.bazel
  26. BZLMOD_SUPPORT.md
  27. CHANGELOG.md
  28. CONTRIBUTING.md
  29. CONTRIBUTORS
  30. internal_dev_deps.bzl
  31. internal_dev_setup.bzl
  32. LICENSE
  33. MODULE.bazel
  34. README.md
  35. RELEASING.md
  36. version.bzl
  37. WORKSPACE
  38. 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

  • Status: Beta
  • Full Feature Parity: No

See Bzlmod support for more details.