What Are Workspaces?
Workspaces are ideal for:- A web application alongside multiple library packages
- A library with performance-critical extensions in Rust/C++
- A plugin system with separate packages per plugin
- Monorepos with related packages versioned together
Shared Lockfile
Single
uv.lock for all workspace members ensures consistent dependenciesIndependent Packages
Each member has its own
pyproject.toml and can be versioned separatelyGetting Started
Create a workspace by adding atool.uv.workspace table to a pyproject.toml:
pyproject.toml
Workspace Configuration
Members and Exclusions
The workspace definition requires:members(required) - Globs matching workspace member directoriesexclude(optional) - Globs excluding specific directories
members (and not excluded) must contain a pyproject.toml file.
Workspace Root
Every workspace needs a root, which is also a workspace member:albatrossis the workspace rootbird-feederis a workspace memberseedsis excluded and not part of the workspace
Workspace Commands
Default Behavior
By default,uv run and uv sync operate on the workspace root:
Running in Specific Members
Use--package to target a specific workspace member:
Locking the Workspace
uv lock operates on the entire workspace at once:
uv.lock with dependencies from all workspace members.
Workspace Sources
Dependencies on workspace members usetool.uv.sources:
pyproject.toml
workspace = true indicates the dependency is provided by a workspace member, not PyPI.
Dependencies between workspace members are always editable.
Inherited Sources
Sources defined in the workspace root apply to all members:pyproject.toml
tqdm from GitHub by default.
Overriding Sources
Members can override workspace sources:packages/bird-feeder/pyproject.toml
Workspace Layouts
Root Project with Libraries
The most common layout has an explicit root with library packages:Virtual Root
A workspace can have a “virtual” root that only aggregates packages:pyproject.toml
When to Use Workspaces
Good Use Cases
Monorepos
Multiple related packages in one repository
Extension Modules
Pure Python with Rust/C++ performance modules
Plugin Systems
Core library with separate plugin packages
Shared Testing
Common test suite across multiple packages
Example: Core + Plugins
pyproject.toml
plugins/auth/pyproject.toml
When NOT to Use Workspaces
Conflicting Requirements
Workspaces share a single lockfile. If members have conflicting requirements, use path dependencies instead:pyproject.toml
- Allows separate virtual environments per package
- Enables fine-grained dependency resolution
- Loses
uv run --packageconvenience
Different Python Versions
Workspaces enforce a singlerequires-python for all members (the intersection of all members’ requires-python values).
If you need to test a member on a Python version unsupported by other members:
Workspace Isolation
Single requires-python
Workspaces take the intersection of all members’requires-python values:
albatross/pyproject.toml
packages/bird-feeder/pyproject.toml
requires-python becomes >=3.11 (the intersection).
Advanced Configuration
Workspace-wide Settings
Some settings in the rootpyproject.toml apply workspace-wide:
pyproject.toml
Member-specific Overrides
Members can override workspace settings:packages/bird-feeder/pyproject.toml
Workspace vs Path Dependencies
- Workspaces
- Path Dependencies
Advantages:
- Shared lockfile ensures consistency
- Single
uv run --packagecommand - Unified dependency resolution
- Automatic member discovery
- Single
requires-pythonfor all members - All members must be compatible
- Shared virtual environment
Migration Strategies
From Single Project
Convert a single project to a workspace:From Path Dependencies
Convert path dependencies to workspace:pyproject.toml
Related Documentation
Projects
Learn about individual project structure
Dependencies
Understand dependency management and sources
Python Versions
Learn about Python version requirements
Cache
Understand how uv caches workspace dependencies