| commit | 7de43d1ea6d03e1c21e864a8249c40aaeb9aaf93 | [log] [tgz] |
|---|---|---|
| author | Ignas Anikevicius <240938+aignas@users.noreply.github.com> | Thu Jun 06 17:20:01 2024 +0900 |
| committer | GitHub <noreply@github.com> | Thu Jun 06 08:20:01 2024 +0000 |
| tree | 91014cbfdb13c29f7f3c15d9fef03ed55fb4a45c | |
| parent | e42f8f4811e57b8c3d19aeaab8f02f9d6a3fd13b [diff] |
feat(bzlmod): support cross-platform whl setups within the main hub repo (#1837)
With this change we add support for platform-specific wheel registration
and
doing the selection of which wheel is used at build time.
This supports:
- Different package versions for different platforms.
- Use string_flags to configure what to fetch/select:
- only whls, only sdist or auto mode.
- libc version and `musl` vs `glibc` selection.
- universal2 vs arch wheels for mac.
- target osx version selection.
Summary of changes:
- The `uv pip install` would only warn the user of yanked packages but
would not refuse to install them. Update our implementation to better
match the same behaviour.
- A previous PR has added the support for passing it in the
`requirements_by_platform` and this just add the necessary code to make
sure that we can also do the dependency management when parsing the
`whl` `METADATA` files.
- Only configure `dev_pip` deps for `linux` and `osx` platforms to not
raise
issues later.
- Add a function for generating a `whl_library` name from a `filename`.
- Add a macro for generating all config settings for a particular set of
parameters.
- Update `render_pkg_aliases` to also use those config settings.
- Update the toolchain selection `target_settings` to use the
`py_linux_libc`
config setting. With this the user can register a `musl` linux toolchain
if
needed. We can also use similar `flag_values` to resolve #1876.
- Integrate everything in the `pip` extension and setup cross-platform
select statements.
Work towards #1357, #260
Stacked on #1937This 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.
Currently, the core rules build into the Bazel binary, and the symbols in this repository are simple aliases. However, we are migrating the rules to Starlark and removing them from the Bazel binary. Therefore, the future-proof way to depend on Python rules is via this repository. SeeMigrating from the Bundled Rules below.
The core rules are stable. Their implementation in Bazel is subject to Bazel's backward compatibility policy. Once migrated to rules_python, they may evolve at a different rate, but this repository will still 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.
For detailed documentation, see https://rules-python.readthedocs.io
See Bzlmod support for more details.