Checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example

Example pixi.toml

[workspace]
authors = [""]
channels = ["conda-forge"]
name = "test"
platforms = ["linux-64"]
version = "0.1.0"

[tasks]

[dependencies]
python = ">=3.13.7,<3.14"

[pypi-dependencies]
triton = { version = ">=3.4.0, <4", index = "https://pypi.org/simple" }
onnx = { version = ">=1.19.0, <2", index = "https://pypi.org/simple" }
pytorch-triton = { version = "*", index = "https://download.pytorch.org/whl/nightly/cu130" }
torch = { version = "*", index = "https://download.pytorch.org/whl/nightly/cu130" }
torchvision = { version = "*", index = "https://download.pytorch.org/whl/nightly/cu130" }

Example shell commands

pixi install # perfectly successful, and do use torch recent version downloaded from cu130 nightly
pixi upgrade # it then will update torch from pypi.org with oldest version, and even rewrite version="*"

Issue description

During pixi upgrade, it seems somehow follow the pypi, rather than follow the "index" provided inside [pypi-dependecies], which seems wired. Or does pixi think stable version (2.8.0) is newer than latest version (2.10.0.devXXXXXXXX)?

I am not so sure about this case, but perhaps I think upgrade should not downgrade the nightly version to stable version?

Besides, I have tried to add "extra-index-urls" in [pypi-options] sections, however, since the "triton" simultaneously happened in both "pypi.org" and "download.pytorch.org", and then pixi just find that in "download.pytorch.org", which also not follows the index, even though I tried different "index-strategy".

Expected behavior

Pixi may should consider the "index" in [pypi-dependencies] as the first priority consideration.
The nightly version should be latest, so pixi upgrade should not revert the version of nightly torch version.