pixi icon indicating copy to clipboard operation
pixi copied to clipboard

change package's channel constraint doesn't invalidate lock file

Open trim21 opened this issue 9 months ago • 2 comments

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


Issue description

2 kind of changes should, but currently doesn't invalidate previous lock file:

update package's channel constraint

change package to a new channel

This is currently resolvable by validating the package's channel in lock file

diff --git a/pixi.toml b/pixi.toml
index 8eef991..b830acb 100644
--- a/pixi.toml
+++ b/pixi.toml
@@ -6,7 +6,7 @@ platforms = ["win-64"]
 channels = ["conda-forge", 'anaconda']
 
 [dependencies]
-python = { version = "3.12.*", channel = "anaconda" }
+python = { version = "3.12.*", channel = "conda-forge" }
 
 # iris = "==3.11.1"
 [activation.env]

remove package's channel constraint

The previous lock file will violate channel priority logic, it's expected to install conda-forge/python in new lock file, but previous lock file has anaconda/python.

This is currently not resolvable, this need a new design on lock file to store channel constraint in lock file.

diff --git a/pixi.toml b/pixi.toml
index 84ba987..36924f4 100644
--- a/pixi.toml
+++ b/pixi.toml
@@ -8,7 +8,7 @@ version = "0.1.0"
 [project]
 channels = ["conda-forge", 'anaconda']

 [dependencies]
-python = { version = "3.12.*", channel = "anaconda" }
+python = { version = "3.12.*"}

Expected behavior

any example should invalidate lock file

trim21 avatar Mar 25 '25 16:03 trim21

Thanks for raising this issue @trim21. I discussed it with @baszalmstra and we agree that the current behaviour goes against what you expect as a user. We could solve it by storing the original specs and comparing if an explicit channel was previously set. However, that would make the lock file even bigger, and I am not confident that this is worth it.

Until then, we always have pixi update :)

Hofer-Julian avatar Apr 07 '25 11:04 Hofer-Julian

However, that would make the lock file even bigger, and I am not confident that this is worth it.

I think we should have some real data point about this...

As a example, github.com/prefix-dev/pixi/pixi.lock is 451 kb, and github.com/prefix-dev/pixi/pixi.toml is just 7.32kb with 48 deps.

For jupyter/notebook, pixi.lock is 212kb and pyproject.toml is 8.17 KB, with only 3 deps

And a single platform (win-64) project I'm currently working on, with 21 deps:

-rw-r--r-- 1 Trim21 197611 61K Apr 7 22:27 pixi.lock -rw-r--r-- 1 Trim21 197611 815 Apr 7 22:26 pixi.toml

if we resolve for all 3 major platforms (win-64, linux-64, osx-arm64):

-rw-r--r-- 1 Trim21 197611 175K Apr 8 05:11 pixi.lock -rw-r--r-- 1 Trim21 197611 838 Apr 8 05:11 pixi.toml

And we only need to store the root spec of the tree, so it will only normally less 1% extra size.

trim21 avatar Apr 07 '25 21:04 trim21