include an example of an independent package with conflicting dependencies to contrast with existing workspace packages

[cameronraysmith]

• https://docs.astral.sh/uv/concepts/projects/workspaces/#when-not-to-use-workspaces

https://github.com/astral-sh/uv/blob/0.6.16/docs/concepts/projects/workspaces.md?plain=1#L150-L199 says:

When (not) to use workspaces

Workspaces are intended to facilitate the development of multiple interconnected packages within a
single repository. As a codebase grows in complexity, it can be helpful to split it into smaller,
composable packages, each with their own dependencies and version constraints.

Workspaces help enforce isolation and separation of concerns. For example, in uv, we have separate
packages for the core library and the command-line interface, enabling us to test the core library
independently of the CLI, and vice versa.

Other common use cases for workspaces include:

• A library with a performance-critical subroutine implemented in an extension module (Rust, C++,
  etc.).
• A library with a plugin system, where each plugin is a separate workspace package with a
  dependency on the root.

Workspaces are not suited for cases in which members have conflicting requirements, or desire a
separate virtual environment for each member. In this case, path dependencies are often preferable.
For example, rather than grouping albatross and its members in a workspace, you can always define
each package as its own independent project, with inter-package dependencies defined as path
dependencies in tool.uv.sources:

[project]
name = "albatross"
version = "0.1.0"
requires-python = ">=3.12"
dependencies = ["bird-feeder", "tqdm>=4,<5"]

[tool.uv.sources]
bird-feeder = { path = "packages/bird-feeder" }

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

This approach conveys many of the same benefits, but allows for more fine-grained control over
dependency resolution and virtual environment management (with the downside that uv run --package
is no longer available; instead, commands must be run from the relevant package directory).

Finally, uv's workspaces enforce a single requires-python for the entire workspace, taking the
intersection of all members' requires-python values. If you need to support testing a given member
on a Python version that isn't supported by the rest of the workspace, you may need to use uv pip
to install that member in a separate virtual environment.

!!! note

As Python does not provide dependency isolation, uv can't ensure that a package uses its declared dependencies and nothing else. For workspaces specifically, uv can't ensure that packages don't import dependencies declared by another workspace member.

We currently include two workspace packages but do not yet have an example of an independent package whose dependency resolution is isolated from that of all the packages in the current workspace.