feat: gracefully handle newer lock-file versions

[baszalmstra]

This PR relaxes the behavior that occurs when pixi encounters a lock-file version that it cannot parse.

Test setup

$ pixi init foobar
$ cd foobar
$ pixi lock

Then manually modify the version in the pixi.lock to be something higher than what is there (I used 7).

Previously

When running any command:

❯ pixi add python
Error:   × Failed to load lock file from `F:\projects\issues\foobar\pixi.lock`
  ╰─▶ The lock file version is 7, but only up to including version 6 is supported by the current version.
  help: Please update pixi to the latest version and try again.

With this PR

❯ pixi add python
  ⚠ Lock-file version 7 is newer than supported
  help: Maximum supported version: 6 (pixi v0.59.0)
        The lock-file will be treated as missing and regenerated.
        Consider updating pixi to the latest version.

✔ Added python >=3.14.0,<3.15

If self_update is enabled the error message will say:

❯ pixi add py-rattler
  ⚠ Lock-file version 7 is newer than supported
  help: Maximum supported version: 6 (pixi v0.59.0)
        The lock-file will be treated as missing and regenerated.
        Consider running `pixi self-update` to update to the latest version.

If --locked or --frozen is specified there is still an error:

❯ pixi install --locked
Error:   × Lock-file version 7 is newer than supported
  help: Maximum supported version: 6 (pixi v0.59.0)
        Cannot continue with --locked or --frozen mode as the lock-file cannot be read.
        Try running `pixi self-update` to update to the latest version.

AI Disclosure

Written by Claude Code, designed by me

[remimimimimi]

I think we should explicitly ask user to confirm that they want to recreate the lockfile, as this action may break some setups like when you didn't staged your changes in a VCS or if you don't use repository at all. Also, then we should add a flag like --yes to always confirm choices like this to not break CI setups.

[baszalmstra]

I think we should explicitly ask user to confirm that they want to recreate the lockfile, as this action may break some setups like when you didn't staged your changed in a VCS or if you don't use repository at all.

This only happens if you (or more likely someone else) used a newer pixi version to generate a lock-file. You pulled that change. Any command you then run with your local (older) pixi will overwrite the upstream changes which I think should be easy to get back.

[tdejager]

The changes look good and promising but what is the best way to test this :)?

[baszalmstra]

I describes the testing procedure in the description of the Pr.

[ruben-arts]

Thank you, this is a great addition! Love the use of the miette diagnostics for this, and great forward-thinking on giving different messages based on self-update.

Works on my machine 👍