Cross-resolve local library dependencies in a monorepo — is there an idiomatic solution with uv?

[Niccolum]

Hi everyone! I'm running a Python monorepo where each local library under src/dp/ has its own Pants resolve and lockfile for isolation. Some libraries depend on other local libraries (declared via pyproject.toml → dependencies).

The problem: When library B depends on library A, B's resolve can't see A's source files — they live in a separate resolve. Tests for B fail because A's source code simply isn't available.

My current workaround: I ended up writing a custom plugin (cross_resolve_lib) that:

1. Reads all pyproject.toml files at startup and builds a dependency graph
2. Creates synthetic xr_sources targets — a custom target type pointing to the producer's .py files but attached to the consumer's resolve
3. Injects the producer's transitive PyPI deps into the consumer's resolve
4. Auto-wires xr_sources into the consumer's test environments via inference rules
5. Populates python-default (a shared resolve for all services) with transitive deps discovered across all local libraries

This is ~400 lines of plugin code that I'd really love to get rid of. It feels like a use case that should be supported natively — especially now that uv is the recommended backend.

Question: Is there an idiomatic Pants + uv way to handle this?

The most promising direction I see is uv workspaces — uv natively treats workspace members as editable local packages that can depend on each other. Does Pants expose any of this? Could a resolve be configured to treat sibling python_distribution targets as workspace members, making cross-library source visibility just work?

As for using a single shared resolve — I'd rather avoid that. The whole point of per-library resolves is to be able to test each library independently against its own declared dependencies. A shared resolve would collapse all those constraints together, making it impossible to verify that a library works correctly in isolation.

I'd love to hear how others are structuring monorepos like this and whether there's a path forward that doesn't require maintaining a custom plugin. Thanks in advance!

[Niccolum]

What I've already tried:

I also attempted to build wheels for local libraries and declare them as dependencies in other resolves. This ran into a fundamental issue: uv doesn't support path_mapping in lockfiles (unlike pip-tools). As a result, the absolute path to the local wheel leaks into the generated lockfile — making it impossible to share the lockfile across machines with different directory layouts. So that approach is a dead end until uv gains path_mapping support.

[VectorPeak]

Pants does not currently expose uv workspaces as a way to make python_distribution targets editable members across resolves. Resolves are still Pants-level partitions, and a first-party dependency edge across different resolves is intentionally not valid. Tests run against source targets + requirement targets in the selected resolve, not against sibling distributions as editable workspace packages.

The native Pants way to model this is to give the producer sources a target in each resolve that is allowed to consume them, usually via target parametrization:

# src/dp/a/BUILD

python_sources(
 name="src",
 resolve=parametrize("dp-a", "dp-b"),
)

python_requirements(
 name="reqs",
 source="pyproject.toml",
 resolve=parametrize("dp-a", "dp-b"),
)

python_tests(
 name="tests",
 resolve="dp-a",
)

# src/dp/b/BUILD

python_sources(
 name="src",
 resolve="dp-b",
)

python_requirements(
 name="reqs",
 source="pyproject.toml",
 resolve="dp-b",
)

python_tests(
 name="tests",
 resolve="dp-b",
)