Dependency Resolution Conflict with `uv` When Using `trackers` as a Dependency

[sunildkumar]

Summary
Hey there! I'm encountering a dependency resolution issue when using trackers as a dependency in my own Python project, which is managed with uv. The way PyTorch is specified as a dependency in trackers makes it very difficult for downstream projects like mine to create a single, reliable lock file that supports multiple hardware backends (e.g., CPU and different CUDA versions).

The Problem

I am trying to offer extras in my own library that correspond to the hardware-specific backends in trackers. My pyproject.toml looks like this:

# In my library's pyproject.toml
[project.optional-dependencies]
cpu = [
    "torch",
    "torchvision",
    "trackers[reid,cpu] @ git+https://github.com/roboflow/trackers.git@..."
]
cu124 = [
    "torch",
    "torchvision",
    "trackers[reid,cu124] @ git+https://github.com/roboflow/trackers.git@..."
]
# ... and so on for other CUDA versions

When I run uv lock or uv sync to resolve my project's dependencies, the process fails with the following error:

error: Requirements contain conflicting indexes for package torch in split ...:
    - https://download.pytorch.org/whl/cpu
    - https://download.pytorch.org/whl/cu118

I believe this occurs because uv attempts to create a "universal" lock file by resolving dependencies for all platforms and all [project.optional-dependencies] at once. The [tool.uv.sources] configuration in your pyproject.toml correctly directs uv to different PyTorch download URLs for each extra (cpu, cu118, etc.). However, when uv evaluates all of them together for a project that consumes them as dependencies, it sees multiple, conflicting sources for the torch package on the same platform (e.g., Linux) and aborts.

While the current setup is very convenient for users who install trackers directly, it is creating significant integration challenges for downstream library authors.

Proposed Solution: Adopt a Peer Dependency Model

A robust and common solution to this problem is to treat PyTorch as a peer dependency.

This would mean:

1. trackers would no longer list torch or torchvision as dependencies. The hardware-specific extras (cpu, cu124, etc.) and the entire [tool.uv] configuration block would be removed from pyproject.toml.
2. The user becomes responsible for installing the correct version of PyTorch for their specific hardware before installing trackers or any library that depends on it.

This is a standard pattern for libraries that build on major ML frameworks like PyTorch, TensorFlow, and JAX.

Benefits of This Approach:

• Resolves the Conflict: It completely eliminates the dependency resolution error for downstream projects.
• Simplifies trackers: It removes the need for the complex [tool.uv] configuration, making the library's packaging much simpler.
• Ecosystem Compatibility: It makes trackers a more "well-behaved" citizen in the Python packaging ecosystem, improving its composability with other tools and libraries.

I believe this change would make trackers even more valuable to the community by improving its ease of use as a dependency.

Would you be open to discussing this change?

Thank you for your consideration.