`pixi update <pkg>` always triggers the update of all git dependencies
Checks
-
[x] I have checked that this issue has not already been reported.
-
[x] I have confirmed this bug exists on the latest version of pixi, using
pixi --version.
Reproducible example
The following project depends on numpy and on tqdm (git based)
git clone https://github.com/fsteinmetz/bug-pixi-git-deps.git
cd bug-pixi-git-deps
pixi update numpy
Output (tqdm has been updated in pixi.lock) :
Environment: default
- C libmpdec 4.0.0 h4bc722e_0
+ C libnsl 2.0.1 hd590300_0
+ C libxcrypt 4.4.36 hd590300_1
~ C numpy 2.2.5 py313h17eae1a_0 -> 2.2.5 py312h72c5963_0
~ C python 3.13.3 hf636f53_101_cp313 -> 3.12.10 h9e4cc4f_0_cpython
~ C python_abi 3.13 6_cp313 -> 3.12 6_cp312
~ P tqdm 4.67.1 -> 4.67.1
Issue description
Any pixi update, here specifically on numpy, triggers the update of all git dependencies, here of tqdm.
Expected behavior
We expect that only numpy and its dependencies are updated, not all git dependencies.
Thank you for this perfect reproducer!
@tdejager is this a known issue on the pypi side, I've not been able to find a related issue.
Not really, we should investigate we have some test to check for minimal lock file updates for PyPI as well. But not sure if that works with pixi update
Just in case : even pixi add triggers such updates (pixi add toml), not only pixi update.
Thanks for your reactivity !
Thanks @fsteinmetz! But @ruben-arts it seems like the conda dependencies have changed right, not the PyPI dependencies.
The tqdm dependency was the problem, which is a PyPI git dependency. The conda dependencies are expected to be updated when you depend on a new version of NumPy.
In this case, only the git ref hash.
Right, I'm sorry I misunderstood. I investigated briefly and I think this has to do with the preferences where we only lock name and version during the PyPI solve. The preferences make sure that these packages are not updated, we should somehow see if we can add the locked git hash here. Preferences are uv/pypi only thing, so that's why the problem occurs there.
The preferences are a bit unflexible in the sense that you have to create requirement.txt like requirement. But that being said, this is a bug, and something we need to look into. Maybe @nichmor is the best person to pick this up at some point.
Any news on this issue ? Editing the lockfile is not a very convenient workaround 😅
This fell under the radar a bit sorry, would still be great if @nichmor could pick it up when he is back!