Support uv as part of rules_python

Just creating this as a placeholder for discussions and documenting some thoughts/findings. rules_uv is doing its job well and replicating the functionality in rules_python would be duplicate effort. However, rules_uv does not support WORKSPACE installations (at least the releases don't advertise such support) and rules_python needs to support WORKSPACE installations.

As a result I see the following options:

Do not support uv. This has a drawback of longer compilation times with the included pip-compile tooling. uv is just a binary and could in theory be later reused for common operations with whl packages.
Support uv only on bzlmod by including rules_uv as a dependency. This would require us to expose rules_uv via @python_versions or something similar so that we don't have loads that load rules_uv within the main //python/*.bzl files to avoid breaking WORKSPACE users. However this would not allow us to use it for our own example testing because they should produce the same output with and without bzlmod. Since we cannot dog-food rules_uv, it makes it a hard proposition.
Write the WORKSPACE deps.bzl implementation for rules_uv so that we can depend on it.
Support uv by copying/reimplementing the uv support as a separate rule/macro whilst not relying on rules_uv. The drawback is that we would have to reimplement parts of it, but the benefit would be that the extra tests that we would need to have would be next to the implementation. We could also provide Windows support in this way as rules_uv does not support Windows yet due to relying on bash scripting for pip_compile.

Current status:

uv pip compile, works with custom authentication helpers.
uv lock, works with custom authentication helpers.
Parse uv.lock and support requirements.txt feature subset, works with bazel downloader, no sdist support.
Downloading and customizing downloaded uv versions.

Oh nice! I've got a POC of a basic uv integration of option 4. The logic is not complicated and it's much simpler if we only need to support blzmod. We can discuss at maintainers meeting, but thats the option I had planned anyway.

@mark-thm

FYI @mark-thm, feel free to write down any thoughts that you may have :)

I don't have any particularly strong feelings here outside of liking uv as the toolchain to use to convert requirements input files to requrements txt files.

We'd be happy to take contributions that add WORKSPACE and/or Windows support. The latter will depend on rules_multitool getting Windows support (very close to landing). The bash scripts are trivial, but do let us customize the uv arguments and return to Bazel an executable, I'm not familiar with how to do that without a bash/batch script but eager to learn.

Besides that, the module is licensed pretty liberally, I don't feel any special ownership over what is otherwise a pretty trivial uv wrapper/there's really no heavy lifting to be done.

So all that said, if y'all would like to copy/replicate/do your own thing here, that's cool with me, too.

Thanks for the comments Mark!

Interesting uv features:

Allow non-file:// paths to serve as --index-url values astral-sh/uv#4524 for having local copies of the index and run unit tests to ensure particular output of uv pip compile.
Add a universal resolution mode to pip compile astral-sh/uv#4505 for having a single requirements.txt file.

I wonder how we could use some of those in the pip.parse and friends, but it would be interesting to experiment with them. Maybe using uv pip install --dry-run or something similar. Some ideas here:

Run uv pip install --dry-run to get the list of packages and versions that one would need to install. Then use that in the hub_repository as a way to construct the select statements or in pip extension evaluation to construct what the parse_requirements function is returning - i.e. requirement per platform.

What would help us drastically is something similar to pip install --dry-run --report.

Just going to repost some of the ideas/convo spawned from the initial PR so they don't get lost.

what do we call the rule that generates the lock file

Based on the discussion:

uv_pip_compile SGTM -- mimics the underlying uv pip compile CLI
Alternatively, we could keep the existing pip_compile name. Just add a backend="uv" attribute which, under the hood, looks up the uv toolchain instead. Or something more advanced like factoring out a common interface both a uv and pip-tools toolchain could implement (as mentioned in the PR)

should running compile be a build action or direct execution?

I'm in favor of making it a build action because its a bit more flexible. Using execution properties, we can control if its run localy, with/without sandboxing, with/without network access, etc, so it can be almost identical to a direct invocation.

We could also have a second target that handles direct invocation.

feat: Introduce an experimental `uv` toolchain (#1989)

Before I forget, having it a build action would make it difficult to provide extra args to e.g. pass args to uv to upgrade a single package in your lockfile. If it is executed via 'run' then you get it for free - you can pass "-U requests" to bump the requests package in your lock file.

Am I missing something here? :)

I think we will end up with various different kinds of rules and actions tbh. Probably some will be build rules, some will be repo rules, some might be macros etc. I think it will depend on the UX and features we end up providing. I personally think uv is just an implementation detail. If folks want to grab or invoke uv directly, they can grab it in a genrule or off the toolchain. There is a runnable current_toolchain atm for example.

fix(uv): fix UV_BIN usage with current_toolchain

fix(uv): fix UV_BIN usage with current_toolchain (#2074)

@aignas

@aignas there are 2 main benefits to doing what I propose.

take full advantage of uv performance improvements to speed up the builds/tests
provide consistent runtime for running test across Bazel and IDE. As it stands, UV venv is not the same as the runtime env that bazel test uses.

Under the hood we create a venv for each py_binary or py_test target and launch tests there. There is no single venv that we are maintaining.

This is what I'm referring to. Using uv to not only create and import the lock file but also to create the venv for each py_binary or py_test

@rickeylev

@rickeylev Since, uv is still in focus and now a priority for 2026, would it be possible to get a statement in this discussion #3391?

Using uv to create the venv for each py_binary or py_test

I'm not sure this will be possible with uv per-se, nor appropriate. In order to create the venv's for the binaries, there's various analysis-phase logic to compute the output files. A custom tool might help optimize that (offloading analysis-phase work to execution phase, somewhat), but the work we're talking about is just mapping paths. It wouldn't use any of uv's tricks for fast venv creation (and sandboxing largely prevents those tricks anyways).

Do we support uv run ? E.g. uv run pyinstaller (in order to build an installer from python sources)? If not, is there some other canonical way to achieve this?

I would say that uv run is just the same as doing run_binary from bazel-skylib where the binary can be defined via py_console_script_binary or py_binary. So I don't think this is in scope for uv support within rules_python. Happy to discuss if I am misunderstanding.

I seem to recall we expose a target that can be run?

uv run foo means

run foo by install all of it's dependencies before it is run.

We provide a target to uv pip compile by passing extra arguments.

fix(pip): parse the index_url from uv.lock file (bazel-contrib#3906)

Do close this ticket need to:

Remove the experimental block from the API docs.

fix(pip.parse): allow uv_lock to be set without requirements_lock (ba…

Just mentioning that uv pip compile which is the only one that rules_uv currently supports is actually quite limited. uv lock and uv export are significantly more powerful in terms of overriding dependencies. This is very useful in monorepos - removing unnecessary dependencies or overriding versions of transitive pip dependencies

feat(python): move to uv.lock via rules_python's uv toolchain, drop r…

Navigation Menu

Repository navigation

Support `uv` as part of `rules_python` #1975

29 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support uv as part of rules_python #1975

Description

Activity

groodt commented on Jun 17, 2024

aignas commented on Jun 17, 2024

mark-thm commented on Jun 17, 2024

aignas commented on Jun 18, 2024

aignas commented on Jun 28, 2024

rickeylev commented on Jul 4, 2024

aignas commented on Jul 14, 2024

groodt commented on Jul 14, 2024

29 remaining items

pablofwcom commented on Jan 8, 2026

pablofwcom commented on Jan 8, 2026

martis42 commented on Feb 22, 2026

rickeylev commented on Feb 23, 2026

peakschris commented on Jun 26, 2026

aignas commented on Jun 27, 2026

rickeylev commented on Jun 27, 2026

aignas commented on Jun 27, 2026

aignas commented on Jul 13, 2026

nikonikolov commented on Jul 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Support `uv` as part of `rules_python` #1975