[FR]: Switch to uv for venv creation and for pip compile

[jab]

What is the current behavior?

• As of #233, to create virtualenv's, aspect_rules_py has maintained its own Rust implementation (that predates uv by only a couple months -- what timing!).

  aspect_rules_py's venv binary does not work on older Linux systems such as RHEL7, resulting in an error like venv: /lib64/libc.so.6: version 'GLIBC_2.18' not found at runtime. Unfortunately this blocks adoption of aspect_rules_py by some organizations that are still stuck on older Linux systems (such as my own).

• For pip compile functionality, aspect_rules_py currently does not provide a solution, leaving this up to the user to handle with some other tool.[1]

Describe the feature

Switching to uv (perhaps even via rules_uv) could provide the following benefits:

• Compatibility: uv (and likewise rules_uv) works on older Linux systems.

• Reduced maintenance costs associated with maintaining aspect_rules_py's own implementation of venv.

• Given how popular uv has already become, uv represents a more "standard" and more field-tested implementation.

• If uv is adopted for venv creation, using it to also provide pip_compile functionality would make aspect_rules_py even more useful.

Subsumes #300.

---

[1] A previous version of this description incorrectly assumed from #300 that aspect_rules_py provides this functionality directly by depending on pip-tools.

[mattem]

The impl in rules_py has some extra considerations for handling things for bazel. A previous blocker for adopting uv was they only provide a binary, with no library API, a request that was closed as not planned when asked.

For pip compile functionality, aspect_rules_py currently calls pip-tools' pip-compile. For pip_compile functionality, switching to uv could provide a dramatic speedup.

rules_py has no dependency on pip-tools, or pip-compile and does not provide this layer. It accepts dependencies from any py_library, how you get those py_library rules for external dependencies is up to the user. For example, there are a number of users that use rules_py with rules_pycross, which provides dependency resolver support for poetry etc. See this Slack post if you are unsure of the layering, https://bazelbuild.slack.com/archives/CA306CEV6/p1716575058135819

Given that we may need to own a layer over uv to provide the required bazel specific parts, I'm unclear how much of the maintenance and support older Linux distros items apply. The rules_py layer is already a thin wrapper over rattler. I'd be happy to accept contributions that add support for older linux distros if that's what is needed.

IMO, the biggest plus to switching to uv would be to use a actively maintained package, rather than rattler, but it would be dependant on a number of constraints.

[jab]

Thanks, makes sense!

And thanks for clarifying about pip-tools here (I'm new to this codebase and got this mistaken impression by misreading "rules_python" in #300's description as "rules_py" 🙃). I've updatead this issue's description accordingly.

[jab]

Interesting, uv "absolutely plans to support [platform-independent lockfiles]". TIL!