Description
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:
- jvolkman@ signs the Google CLA (done already, can check internal signcla page for jvolkman) and then sends a pull request contributing his code. This is treated like any other pull request, and rules_python then owns the code.
- Copy the rules_pycross code in a top-level third_party directory. Any existing LICENSE and copyright headers must be preserved. If we edit a file, we must modify the copyright header to include Google LLC.
(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
- jvolkman@ sends PR contributing code
- Rename to remove "pycross" prefixes
- Figure out public API surface
- Integrate with existing workspace/bzlmod build styles