Should my team's project structure work as a uv workspace?

[omer54463]

Question

My team uses a certain project structure:

1. The code is divided into python packages (each with its own pyproject.toml) inside a source directory.
2. The (pytest) tests are their own module, just like pytest likes it.

Currently, we have a PowerShell installation script that installs all those packages in editable mode, and that's the way we work.

- source:
  - package_1:
    - pyproject.toml
    - package_1:
      - __init__.py
      - py.typed
      - ...
  - package_2:
    - pyproject.toml
    - package_2:
      - __init__.py
      - py.typed
      - ...
- test:
  - __init__.py
  - conftest.py
  - unit:
    - __init__.py
    - test_something.py
    - ...

I created an example of the same structure, and added my attempt at converting it into a uv workspace.

I encountered two problems:

1. I can't install development dependencies. uv pip install .[dev] fails with "Failed to parse metadata from built wheel".
2. I am not sure if there's an automatic way I can tell uv to install all my workspace packages.

Any help would be much appreciated. uv is awesome and incredibly fast, and I would love to use it!

Platform

Windows 11 x86_64

Version

uv 0.5.29 (ca73c47 2025-02-05)

[konstin]

I can't install development dependencies. uv pip install .[dev] fails with "Failed to parse metadata from built wheel".

Your root pyproject.toml doesn't belong to a package, so uv pip install . falls back to a bogus setuptools build, I opened #11382 to show a better error message here.

In your example, are you looking for the dev group instead of the dev extra?

I am not sure if there's an automatic way I can tell uv to install all my workspace packages.

You can do that with uv sync --all-packages.

[omer54463]

Thanks @konstin!

I'm pretty sure I want the dev group, since I want development dependencies there. According to the documentation:

• project.dependencies: Published dependencies.
• project.optional-dependencies: Published optional dependencies, or "extras".
• dependency-groups: Local dependencies for development.
• tool.uv.sources: Alternative sources for dependencies during development.

Those are global to the workspace, where would you put those instead of that workspace-level pyproject.toml (which cannot be installed)?

Also, about that sync thing, I just tried it out, and it doesn't seem like it installed my packages:

> uv sync --all-packages
> uv pip list
Package           Version
----------------- -------
colorama          0.4.6
iniconfig         2.0.0
mypy              1.15.0
mypy-extensions   1.0.0
packaging         24.2
pluggy            1.5.0
pytest            8.3.4
ruff              0.9.5
typing-extensions 4.12.2

As you can see, no editable (or otherwise) installations calculator and calculator-backend.
Am I missing something?

[konstin]

Those are global to the workspace, where would you put those instead of that workspace-level pyproject.toml (which cannot be installed)?

Placing dependency groups in the root is also what I'd recommend here. Dependency groups are subtly different from the other dependency kinds, as you can have [dependency-groups] without a [project] table, and you can install groups without installing (or building) any project. The project root pyproject.toml in your example looks correct for the structure you're trying to achieve.

As you can see, no editable (or otherwise) installations calculator and calculator-backend.
Am I missing something?

That's somewhat unintuitive: The packages aren't synced since they don't declare a [build-system], so uv assumed they can't be build. Adding a build system entry, such as uv's default, will make the packages be installed with uv sync --all-packages:

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

(You can of course use any build backend, not just hatchling)