What happened?
Related issue: bazel-contrib/rules_python#1791
Summary
aspect_rules_py uv hubs are not isolated across bzlmod modules when two modules use the same uv project / dependency-group name.
A downstream module can directly depend on a package from its own uv hub, for example @bar_uv_deps//matplotlib, but Bazel can resolve that label through the upstream module's generated uv project and lockfile result.
Reproduction
There are two projects: foo and bar.
foo/pyproject.toml:
[project]
name = "runtime"
dependencies = [
"build",
"matplotlib",
]
foo/uv.lock resolves matplotlib 3.9.4.
bar/pyproject.toml:
[project]
name = "runtime"
dependencies = [
"build",
"matplotlib<=3.7.0",
]
bar/uv.lock resolves matplotlib 3.7.0.
bar/BUILD.bazel directly depends on its own uv hub label:
py_binary(
name = "main",
srcs = ["main.py"],
deps = [
"@foo",
"@bar_uv_deps//matplotlib",
],
)
Run:
Since bar directly depends on @bar_uv_deps//matplotlib, and bar/uv.lock contains matplotlib 3.7.0, the binary should run with:
matplotlib version: 3.7.0
The binary runs with matplotlib 3.9.4
Workarounds considered
Using virtual_deps / resolutions can work only if the whole relevant dependency graph cooperates by exposing third-party packages as virtual dependencies.
Giving the two uv projects distinct names, such as foo-runtime and bar-runtime, avoids the collision because the generated repos become distinct:
project__bar_runtime//:matplotlib
whl_install__bar_runtime__matplotlib__3_7_0
If duplicate project / dependency-group names across Bzlmod modules are unsupported, it would be better to fail clearly rather than silently selecting another module's package version.
Version
Development (host) and target OS/architectures: linux x86_64
Output of bazel --version: 9.1.1
Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file: bazel_dep(name = "aspect_rules_py", version = "2.0.0-alpha.1")
Language(s) and/or frameworks involved: python
How to reproduce
Example project:
https://github.com/finn-ball/python_bzlmod_test/tree/finn/rules_py
Any other information?
No response
What happened?
Related issue: bazel-contrib/rules_python#1791
Summary
aspect_rules_pyuv hubs are not isolated across bzlmod modules when two modules use the same uv project / dependency-group name.A downstream module can directly depend on a package from its own uv hub, for example
@bar_uv_deps//matplotlib, but Bazel can resolve that label through the upstream module's generated uv project and lockfile result.Reproduction
There are two projects:
fooandbar.foo/pyproject.toml:foo/uv.lockresolves matplotlib3.9.4.bar/pyproject.toml:bar/uv.lockresolves matplotlib3.7.0.bar/BUILD.bazeldirectly depends on its own uv hub label:Run:
Since
bardirectly depends on@bar_uv_deps//matplotlib, andbar/uv.lockcontains matplotlib3.7.0, the binary should run with:The binary runs with matplotlib
3.9.4Workarounds considered
Using
virtual_deps/resolutionscan work only if the whole relevant dependency graph cooperates by exposing third-party packages as virtual dependencies.Giving the two uv projects distinct names, such as
foo-runtimeandbar-runtime, avoids the collision because the generated repos become distinct:If duplicate project / dependency-group names across Bzlmod modules are unsupported, it would be better to fail clearly rather than silently selecting another module's package version.
Version
Development (host) and target OS/architectures: linux x86_64
Output of
bazel --version: 9.1.1Version of the Aspect rules, or other relevant rules from your
WORKSPACEorMODULE.bazelfile: bazel_dep(name = "aspect_rules_py", version = "2.0.0-alpha.1")Language(s) and/or frameworks involved: python
How to reproduce
Any other information?
No response