Building and publishing uv workspace members with pinned version constraints

[mtnmbr]

Hey,

first of all. Thanks a lot for your efforts on making the python tooling ecosystem better! I love ruff and uv :). Please keep up the great work.

I am currently migrating an existing monorepo from poetry using the poetry-monorepo-dependency-plugin to uv.

I thought that uv workspaces should be the way to handle this usecase.

The current setup looks somewhat like this:

uv_monorepo
│   .gitignore
│   .python-version
│   pyproject.toml
│   README.md
│   uv.lock
│
├───package_a
│   │   pyproject.toml
│   │   README.md
│   │
│   └───src
│       └───package_a
│               py.typed
│               __init__.py
│
├───package_b
│   │   pyproject.toml
│   │   README.md
│   │
│   └───src
│       └───package_b
│               py.typed
│               __init__.py
│
└───package_c
    │   pyproject.toml
    │   README.md
    │
    └───src
        └───package_c
                py.typed
                __init__.py

uv tree gives the following output to show the inter_package dependecies:

#uv tree
Using CPython 3.12.1
Resolved 4 packages in 13ms
package-a v0.1.0
└── package-b v0.2.0
    └── package-c v0.3.0
uv-monorepo v0.1.0

So my previous setup did allow me to publish the packages individually to our internal pypi mirror with pinned versions of the dependencies.

My main pyproject.toml looks like this atm. (in reality the workspace members are added to the toplevel virtual workspace package to be able to omit the --al--packages on uv sync):

[project]
name = "uv-monorepo"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.12"
dependencies = []


[tool.uv.workspace]
members = ["package_a", "package_b", "package_c"]

With e.g. the package_a pyproject.toml being:

[project]
name = "package-a"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.12"
dependencies = [
    "package-b",
]

[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

[tool.uv.sources]
package-b = { workspace = true }

This demo setup has basically been fully created with several uv init calls.

The hope was that uv build --package-a --wheel would output a wheel that has the pinned lower version of the dependency package-b listed internally. At least this is what my previous setup did.
Instead I get a METADATA file like this:

Metadata-Version: 2.3
Name: package-a
Version: 0.1.0
Summary: Add your description here
Requires-Python: >=3.12
Requires-Dist: package-b

When published to our pypi instance this would ofcource not resolve to the actual boundary of package-b>=0.2.0,<0.3 that would be required here.

After bumping e.g. the patch version of package-b I would also assume that the version inside the METADATA is bumped to e.g. 0.2.1.

Is this use-case supported? What is the current approach to handle this properly? I am open for suggestions!

Best regards
Michael

[gracevivi523]

I have opened this issue and I think we are trying to achieve the same goal.

[zanieb]

Related

• Build a wheel using pinned/resolved dependencies from uv.lock? #8729
• Add uv.workspace.dependencies to share dependency versions across workspace members #8949

(though I think this request is distinct)

[zanieb]

It would be nice to have some automated support for this, but, as described in the linked issues, it's sort of hard to do this in a spec-compliant way. We haven't designed a solution for this category of problem yet.

[mtnmbr]

Hey, thanks for the pointing out the related topics. I must have overlooked #8729 for some reason.

I think it's the one most related to my problem.

So as for now there is no standard way to do this. In the meanwhile do you have any suggestions on how to handle this?

I mean for version bumping I am using a separate tool anyways atm. So I might give it a try to manually add the version constraint in the dependency groups and make that tool update the other pyproject.toml files as well.

Though maybe not intended it at least did not seem to break anything when adding version constraints on workspace members (funny enough not even if the version does not match the one in the workspace at all)

[mtnmbr]

So this is not fully related to the marked issue but at least covered by it. Maybe this is even possible for only workspaces?