It's not safe, for two reasons:
1. Dependency confusion. uv's default, first-index, exists to block attacks
where someone publishes a package with the same name on a different index.
The torchtriton compromise in December 2022 happened this way, through the
PyTorch nightly index. The "unsafe-" strategies turn that protection off
for every package, not just torch [uv-threads/docs/concepts/indexes.md].
2. Old versions of ordinary packages. The PyTorch index also hosts outdated
copies of common packages. With this strategy, uv picks the first index
that has a compatible version, even when PyPI has a newer one. In a
reported case this pulled certifi==2022.12.7, so the SSL certificates were
two years out of date. idna, packaging, pillow, jinja2 and others were also
downgraded [https://github.com/astral-sh/uv/issues/3137],
[https://github.com/astral-sh/uv/issues/3137#issuecomment-2066688806]. Your
pyproject.toml:5 lists certifi with no version bound, so you're exposed to
exactly this.
The better setup is to pin only torch to the PyTorch index and mark that index
explicit, so nothing else can come from it. Then remove index-strategy so
you're back on the safe default [uv-threads/docs/concepts/indexes.md]:
[project]
name = "ml-service"
version = "0.1.0"
requires-python = ">=3.11"
dependencies = ["torch>=2.3", "fastapi>=0.110", "certifi"]
[tool.uv.sources]
torch = { index = "pytorch-cpu" }
[[tool.uv.index]]
name = "pytorch-cpu"
url = "https://download.pytorch.org/whl/cpu"
explicit = true
This also replaces the old extra-index-url with a named [[tool.uv.index]]. The
named index has to be defined in pyproject.toml itself. uv won't recognise a
tool.uv.sources pin that points to an index set on the command line, in
environment variables or in user-level config
[uv-threads/docs/concepts/indexes.md]. If you ever need CUDA builds on Linux,
you can give torch a list of sources chosen by platform markers.
Want me to apply this and re-lock with uv lock?
