Repository navigation
Support uv as part of rules_python #1975
Description
Activity
- changed the title
[-]Support `uv` as part of `rules_python`[/-][+]Discuss: support `uv` as part of `rules_python`[/+]on Jun 17, 2024 Oh nice! I've got a POC of a basic
uvintegration 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.I don't have any particularly strong feelings here outside of liking
uvas 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
uvwrapper/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.
Reacted by Greg RoodtReacted by Ignas Anikevicius, Greg Roodt, J Schmidt and Alberto CavalcanteThanks for the comments Mark!
- changed the title
[-]Discuss: support `uv` as part of `rules_python`[/-][+]Support `uv` as part of `rules_python`[/+]on Jun 26, 2024 Interesting
uvfeatures:- Allow non-file:// paths to serve as
--index-urlvalues astral-sh/uv#4524 for having local copies of the index and run unit tests to ensure particular output ofuv pip compile. - Add a universal resolution mode to
pip compileastral-sh/uv#4505 for having a singlerequirements.txtfile.
I wonder how we could use some of those in the
pip.parseand friends, but it would be interesting to experiment with them. Maybe usinguv pip install --dry-runor something similar. Some ideas here:Run
uv pip install --dry-runto get the list of packages and versions that one would need to install. Then use that in thehub_repositoryas a way to construct the select statements or inpipextension evaluation to construct what theparse_requirementsfunction is returning - i.e. requirement per platform.What would help us drastically is something similar to
pip install --dry-run --report.Reacted by pablofwcom- Allow non-file:// paths to serve as
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_compileSGTM -- mimics the underlyinguv pip compileCLI- Alternatively, we could keep the existing
pip_compilename. Just add abackend="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.
Reacted by Greg Roodt- added a commit that references this issue
on Jul 12, 2024 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? :)
Reacted by Greg RoodtI 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
uvis just an implementation detail. If folks want to grab or invokeuvdirectly, they can grab it in a genrule or off the toolchain. There is a runnablecurrent_toolchainatm for example.- added a commit that references this issue
on Jul 18, 2024 - added a commit that references this issue
on Jul 19, 2024 29 remaining items
@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 testuses.
Under the hood we create a venv for each
py_binaryorpy_testtarget and launch tests there. There is no singlevenvthat 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_binaryorpy_test@rickeylev Since,
uvis 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).
- pinned this issue
on Apr 15, 2026 - added a sub-issue
on Jun 1, 2026 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 runis just the same as doingrun_binaryfrombazel-skylibwhere the binary can be defined viapy_console_script_binaryorpy_binary. So I don't think this is in scope foruvsupport withinrules_python. Happy to discuss if I am misunderstanding.I seem to recall we expose a target that can be run?
uv run foomeansrun
fooby install all of it's dependencies before it is run.We provide a target to
uv pip compileby passing extra arguments.Do close this ticket need to:
- Remove the
experimentalblock from the API docs.
- Remove the
- added a commit that references this issue
on Jul 27, 2026 Just mentioning that
uv pip compilewhich is the only one thatrules_uvcurrently supports is actually quite limited.uv lockanduv exportare significantly more powerful in terms of overriding dependencies. This is very useful in monorepos - removing unnecessary dependencies or overriding versions of transitive pip dependencies- added a commit that references this issue
on Sep 11, 2026
Just creating this as a placeholder for discussions and documenting some thoughts/findings.
rules_uvis doing its job well and replicating the functionality inrules_pythonwould be duplicate effort. However,rules_uvdoes not supportWORKSPACEinstallations (at least the releases don't advertise such support) andrules_pythonneeds to supportWORKSPACEinstallations.As a result I see the following options:
uv. This has a drawback of longer compilation times with the includedpip-compiletooling.uvis just a binary and could in theory be later reused for common operations with whl packages.uvonly onbzlmodby includingrules_uvas a dependency. This would require us to exposerules_uvvia@python_versionsor something similar so that we don't have loads that loadrules_uvwithin the main//python/*.bzlfiles to avoid breakingWORKSPACEusers. 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-foodrules_uv, it makes it a hard proposition.WORKSPACEdeps.bzlimplementation forrules_uvso that we can depend on it.uvby copying/reimplementing theuvsupport as a separate rule/macro whilst not relying onrules_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 asrules_uvdoes not support Windows yet due to relying onbashscripting forpip_compile.Current status:
uv pip compile, works with custom authentication helpers.uv lock, works with custom authentication helpers.uv.lockand supportrequirements.txtfeature subset, works with bazel downloader, no sdist support.uvversions.