Pixi lock file out of date with new pixi / lock format version

[fpaniagua]

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

pixi install --locked --environment prod

lock-file not up-to-date with the project

Lock file generated by pixi v0.20.0.

System pixi now at v0.21.1.

Issue description

In a dockerfile pointing to pixi latest.

Expected behavior

I could be misunderstanding locked vs frozen. Or just what is expected on locked when using upgraded pixi.

My intention on using --locked in places was to ensure that when manifest is updated, lock file is also in sync.

This appears to fail when lockfile format version changes.

Using just --frozen works to install the environment, but now not sure if up to date with manifest.

Is this intentional?

[baszalmstra]

That is strange, could you run the command with -v? That will tell us why the lockfile is out of date.

[fpaniagua]

Interesting.

So going back to prior version of pyproject.toml, and re-generating lock via v0.20.1

$ ~/.pixi/bin/pixi --version
pixi 0.20.1
$ rm pixi.lock
$ ~/.pixi/bin/pixi install
✔ Project in <abc> is ready to use!

Now validating lock file via a task run

$ ~/.pixi/bin/pixi --version
pixi 0.20.1
$ ~/.pixi/bin/pixi run --locked --environment <abc> some-task
$ echo $?
0

Now trying pixi v0.21.1

$ pixi --version
pixi 0.21.1
$ pixi run --locked --environment <abc> some-task
  × lock-file not up-to-date with the project
$ pixi run -v --locked --environment <abc> some-task
...
 INFO pixi::lock_file::outdated: environment '<xyz>' is out of date because the channels in the lock-file do not match the environments channels
  × lock-file not up-to-date with the project

is an entirely different environment than .

I will see if I can get to a minimally reproducable pixi.toml or pyproject.toml.

[fpaniagua]

This seems to reproduce:

# pyproject.toml
[project]
name = "pixi-example"
requires-python = ">=3.11"

[tool.pixi.project]
name = "pixi-example"
channels = ["conda-forge"]
platforms = ["linux-64", "osx-arm64"]

[tool.pixi.tasks]

[tool.pixi.feature.prod]
channels = ["conda-forge", "pytorch"]

[tool.pixi.feature.prod.dependencies]
python = "3.11.*"

[tool.pixi.feature.empty.dependencies]

[tool.pixi.environments]
default = {features = ["prod"], solve-group = "default"}
prod = {features = ["prod"], solve-group = "default"}
empty = {features = ["empty"], solve-group = "default"}

$ ~/.pixi/bin/pixi --version
pixi 0.20.1
$ ~/.pixi/bin/pixi install       
✔ Project in /<abc>/pixi-example is ready to use!
$ ~/.pixi/bin/pixi install --locked
✔ Project in /<abc>/pixi-example is ready to use!

$ pixi --version
pixi 0.21.1
$ pixi install --locked --verbose
 INFO pixi::config: Global config not found at /etc/pixi/config.toml
 INFO pixi::config: Global config not found at /<abc>/.config/pixi/config.toml
 INFO pixi::config: Global config not found at /<abc>/Library/Application Support/pixi/config.toml
 INFO pixi::config: Global config not found at /<abc>/.pixi/config.toml
 INFO pixi::environment: verifying prefix location is unchanged, with prefix file: /<abc>/pixi-example/.pixi/envs/default/conda-meta/pixi_env_prefix
 INFO pixi::lock_file::outdated: environment 'empty' is out of date because the channels in the lock-file do not match the environments channels
  × lock-file not up-to-date with the project

[fpaniagua]

So i re-generated lock file via v0.21.1, and saw the empty environment has the same channels as the prod/default:

environments:
  default:
    channels:
    - url: https://conda.anaconda.org/conda-forge/
    - url: https://conda.anaconda.org/pytorch/
...
  empty:
    channels:
    - url: https://conda.anaconda.org/conda-forge/
    - url: https://conda.anaconda.org/pytorch/
...
  prod:
    channels:
    - url: https://conda.anaconda.org/conda-forge/
    - url: https://conda.anaconda.org/pytorch/

I noticed I had them share the same solve group. So attempted a version with that modified:

empty = {features = ["empty"], solve-group = "empty"}

Now --locked validation works with v0.21.1 on a v0.20.1 generated lock file.

[baszalmstra]

Ah right! There was indeed a bug in older versions where the channels were not properly recorded for an environment in the presence of solve groups.