Skip to content
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

refactor(whl_library): split wheel downloading and extraction into separate executions #1487

Merged
merged 1 commit into from
Oct 17, 2023

Conversation

aignas
Copy link
Collaborator

@aignas aignas commented Oct 12, 2023

Before the PR the downloading/building of the wheel and the extraction
would be done as a single step, which meant that for patching of the
wheel to happen, we would need to do it within the python script. In
order to have more flexibility in the approach, this PR splits the
process to two separate invocations of the wheel_installer, which
incidentally also helps in a case where the downloading of the wheel
file can happen separately via http_file.

Related issues #1076, #1357

…parate executions

Before the PR the downloading/building of the wheel and the extraction
would be done as a single step, which meant that for patching of the
wheel to happen, we would need to do it within the python script. In
order to have more flexibility in the approach, this PR splits the
process to two separate invocations of the wheel_installer, which
incidentally also helps in a case where the downloading of the wheel
file can happen separately via http_file.
@aignas
Copy link
Collaborator Author

aignas commented Oct 13, 2023

Note, that with this we could in theory set up a cyclic dependency test with:

  • Creating a repository rule that creates two wheels via the py_wheel.
  • Creating two whl_library rules that instead of downloading a wheel from requirements use the wheel targets provided by the py_wheel.

@@ -86,7 +86,9 @@ py_library(
"""

def generate_whl_library_build_bazel(
*,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: can we call it *args?

I'm not entirely following why we need this? Can you elaborate?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is to force all of the arguments to be specified as keyword arguments. this function has lots of arguments and supporting positional arguments may be a little bit error prone.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, right. of course.

Copy link
Collaborator

@groodt groodt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@aignas aignas added this pull request to the merge queue Oct 17, 2023
Merged via the queue into bazelbuild:main with commit 915d7a0 Oct 17, 2023
1 check passed
@aignas aignas deleted the feat/1076/refactor-whl-library branch October 17, 2023 05:34
github-merge-queue bot pushed a commit that referenced this pull request Oct 20, 2023
Before that the users had to rely on patching the actual wheel files and
uploading them as different versions to internal artifact stores if they
needed to modify the wheel dependencies. This is very common when
breaking dependency cycles in `pytorch` or `apache-airflow` packages.
With this feature we can support patching external PyPI dependencies via
pip.override tag class to fix package dependencies and/or a broken
`RECORD` metadata file.

Overall design:
* Split the `whl_installer` CLI into two parts - downloading and
extracting.
  Merged in #1487.
* Add a starlark function which extracts the downloaded wheel applies
patches
  and repackages a wheel (so that the extraction part works as before).
* Add a `override` tag_class to the `pip` extension and allow users to
pass patches
  to be applied to specific wheel files.
* Only the root module is allowed to apply patches. This is to avoid far
away modules
modifying the code of other modules and conflicts between modules and
their patches.

Patches have to be in `unified-diff` format.

Related #1076, #1166, #1120
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants