-
Notifications
You must be signed in to change notification settings - Fork 542
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
exp: multi-arch whl_library in bzlmod #1625
Conversation
…t may be possible to get them working
Conflicts: * python/pip_install/private/generate_whl_library_build_bazel.bzl
With this PR we can deterministically parse the METADATA and generate a `BUILD.bazel` file using the config settings introduced in #1555. Let's imagine we had a `requirements.txt` file that used only wheels, we could use the host interpreter to parse the wheel metadata for all the target platforms and use the version aware toolchain at runtime. This potentially unlocks more clever layouts of the `bzlmod` hub repos explored in #1625 where we could have a single `whl_library` instance for all versions within a single hub repo. Work towards #1643.
Given the latest developments and https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593, this is paused for some time. |
Some notes on the implementation of how this could be done reasonably cleanly.
If we would need to somehow split the whl hub and pip hub generation, then we would need to do as follows:
In the second option the user would use it as: pypi = use_extension("@rules_python//python/extensions/pypi.bzl", "pypi")
# The following can be called multiple times
pypi.index_requirements(
index_url = "foo",
extra_index_urls = ["bar"],
srcs = [
"//:my_requirements.txt",
],
)
use_repo(pypi, "pypi_index")
pip = use_extension("@rules_python//python/extensions/pip.bzl", "pip")
pip.index(index="@pypi_index//:packages.json") # contains the package and the labels to the metadata files for each package.
# Use stuff as previously.
pip.parse(
hub_repo = "pip",
src = "//:my_requirements.txt",
) |
This is a variant of bazelbuild#1625 and was inspired by bazelbuild#1788. In bazelbuild#1625, we attempt to parse the simple API HTML files in the same `pip.parse` extension and it brings the follownig challenges: * The `pip.parse` cannot be easily use in `isolated` mode and it may be difficult to implement the isolation if bazelbuild/bazel#20186 moves forward. * Splitting the `pypi_index` out of the `pip.parse` allows us to accept the location of the parsed simple API artifacts encoded as a bazel label. * Separation of the logic allows us to very easily implement usage of the downloader for cross-platform wheels. * The `whl` `METADATA` might not be exposed through older versions of Artifactory, so having the complexity hidden in this single extension allows us to not increase the complexity and scope of `pip.parse` too much. * The repository structure can be reused for `pypi_install` extension from bazelbuild#1728. TODO: - [ ] Add unit tests for functions in `pypi_index.bzl` bzlmod extension if the design looks good. - [ ] Changelog. Out of scope of this PR: - Further usage of the downloaded artifacts to implement something similar to bazelbuild#1625 or bazelbuild#1744. This needs bazelbuild#1750 and bazelbuild#1764. - Making the lock file the same on all platforms - We would need to fully parse the requirements file. - Support for different dependency versions in the `pip.parse` hub repos based on each platform - we would need to be able to interpret platform markers in some way, but `pypi_index` should be good already. - Implementing the parsing of METADATA to detect dependency cycles. - Support for `requirements` files that are not created via `pip-compile`. - Support for other lock formats, though that would be reasonably trivial to add. Open questions: - Support for VCS dependencies in requirements files - We should probably handle them as `overrides` in the `pypi_index` extension and treat them in `pip.parse` just as an `sdist`, but I am not sure it would work without any issues.
Will re-implement this in separate PRs. |
This is a reasonably polished POC to support bazel downloader to fetch wheels
and to setup multi-platform whl targets which would allow us to almost
correctly setup the dependency tree.
In general usecase this yield great performance improvements whilst running the
tests as the fetching of the wheels is much faster.
Ideas for improvements: