Pull rules_pycross into rules_python #1360
Labels
Comments
|
Who is working on this? |
|
Option 1 LGTM if LGTY @jvolkman |
|
I assume it's me working on this, but we're camping this week so I won't be able to get to it until after. |
philsc
added a commit
to philsc/rules_python
that referenced
this issue
Sep 4, 2023
This patch imports a few files from jvolkman/rules_pycross at 757033ff8afeb5f7090b1320759f6f03d9c4615c. I would like to re-use this rule for the `pypi_install` repo rule that I'm working on. This rule extracts a downloaded wheel and generates an appropriate `PyInfo` provider for it. All the non-BUILD files are taken as-is without modification. A followup patch will make tweaks so that the code can be used from within rules_python. References: bazelbuild#1360
philsc
added a commit
to philsc/rules_python
that referenced
this issue
Sep 8, 2023
Since I couldn't figure out how to disable buildifier from third_party code, I let buildifier do its thing. This necessitated adding the copyright headers as per bazelbuild#1360.
github-merge-queue bot
pushed a commit
that referenced
this issue
Sep 8, 2023
This patch imports a few files from jvolkman/rules_pycross at 757033ff8afeb5f7090b1320759f6f03d9c4615c. I would like to re-use this rule for the `pypi_install` repo rule that I'm working on. This rule extracts a downloaded wheel and generates an appropriate `PyInfo` provider for it. All the .pyfiles are taken as-is without modification. I had to run buildifier on all the bazel-related files. As per #1360, that meant that I had to add copyright headers. A followup patch will make tweaks so that the code can be used from within rules_python. References: #1360
philsc
added a commit
to philsc/rules_python
that referenced
this issue
Sep 13, 2023
This patch changes the name of the rule to reflect the fact that it's not exactly the same as the one in rules_pycross. I also took this opportunity to delete the superfluous `namespace_pkgs.py` library (plus test) since we have a nearly identical version already in the main repo. I added a test to validate that the rule functions at a basic level. References: bazelbuild#1360
philsc
added a commit
to philsc/rules_python
that referenced
this issue
Sep 13, 2023
This patch changes the name of the rule to reflect the fact that it's not exactly the same as the one in rules_pycross. I also took this opportunity to delete the superfluous `namespace_pkgs.py` library (plus test) since we have a nearly identical version already in the main repo. I added a test to validate that the rule functions at a basic level. References: bazelbuild#1360
github-merge-queue bot
pushed a commit
that referenced
this issue
Sep 27, 2023
This patch changes the name of the rule to reflect the fact that it's not exactly the same as the one in rules_pycross. I also took this opportunity to delete the superfluous `namespace_pkgs.py` library (plus test) since we have a nearly identical version already in the main repo. I added a test to validate that the rule functions at a basic level. References: #1360
philsc
added a commit
to philsc/rules_python
that referenced
this issue
Sep 28, 2023
This patch adds a few arguments to `py_wheel_library` to simulate how `http_archive` accepts patch-related arguments. I also amended the existing test to validate the behaviour at a very high level. References: bazelbuild#1360
github-merge-queue bot
pushed a commit
that referenced
this issue
Dec 19, 2023
This patch adds a few arguments to `py_wheel_library` to simulate how `http_archive` accepts patch-related arguments. I also amended the existing test to validate the behaviour at a very high level. References: #1360
|
This issue has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days. |
github-actions
bot
added
the
Can Close?
|
Since the robots are gonna close this soonish, are we still aiming to do this? |
github-actions
bot
removed
the
Can Close?
ewianda
added a commit
to ewianda/rules_python
that referenced
this issue
Jun 20, 2024
ewianda
added a commit
to ewianda/rules_python
that referenced
this issue
Jun 20, 2024
|
Code was vendored here https://github.com/bazelbuild/rules_python/tree/main/third_party/rules_pycross Closing this as the code is ported which completes the main motivators here. We have yet to really use or take advantage of the code. Plans have changed as well so perhaps we won't end up using the code after all. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A recurring source of issues in rules_python is the underlying support for how wheels are handled, mainly that support for multiple platforms and versions doesn't work very well because a lot of activity happens at repo-rule time. Several of us have been looking at different parts of this problem, and we've generally come to the conclusion that a more idealized implementation is more akin to having simple http_file download's of the pypi artifacts, and moving any subsequent logic out of repo-rule time and into the regular build phase. This is a pretty big change in how things are done.
Luckily for us, @jvolkman's rules_pycross has done much of this already, and he's said its OK for us to take that code.
Per Google's rules, there are two ways we can do this:
(1) is preferred because it's just less overhead in the long run.
I suggest we ask Jeremy to simply do a one-time code-dump it into
//python/private/pycross_staging, then we can start picking it apart as necessary. This avoids the extra overhead of license and copyright management from (2), and having to ask Jeremy to send a PR for some new piece of pycross we want to reuse.After its ingested, we can rename things to drop the "pycross" prefixes, figure out appropriate APIs we wish to expose, how to integrate with our existing code, etc
The text was updated successfully, but these errors were encountered: