fix: tone down lockfile format and deprecation warnings on read-only commands

[wolfv]

Description

Everyday commands like pixi run, pixi shell, and pixi list no longer nag about things that don't affect them. Deprecation warnings (such as the legacy [system-requirements] table and [package.target] tables) are now only shown by commands that update the lock file or modify the manifest, and the old-lockfile-format notice is demoted to info on the read path.

Original request: "My friend was complaining about the lockfile warning in Pixi - maybe we can make that less aggressive? E.g. not on pixi run and other operations - because using an old lockfile is totally fine for now. Same / similar for the system requirements -> fancy platforms deprecation - toning it down to only fire when updating? or modifying pixi.toml"

Key changes:

1. Added emit_deprecation_warnings flag to WorkspaceLocator (default false), following the existing ignore_unused_feature_warnings pattern, plus a Warning::is_deprecation() helper. Deprecation warnings are filtered out of the manifest-warning report unless the command opts in.

2. Opt-in via with_deprecation_warnings(true) for the commands where migrating is actually relevant:

   • Lock file updates: pixi lock, pixi update, pixi upgrade
   • Manifest modification: pixi add, pixi remove, pixi import
   • Workspace config: pixi workspace channel | description | environment | feature | name | platform | requires-pixi | version

3. Lock file format notice demoted from warn to info on the read path in update_lock_file(). An old but up-to-date lock file is perfectly usable; pixi lock still performs and reports the actual format upgrade (that path is unchanged).

4. Documentation: docs/workspace/system_requirements.md now states when the deprecation warning appears.

Note: pixi install is deliberately in the quiet group, treated like pixi run as an everyday materialization command. Easy to flip if reviewers prefer it noisy.

How Has This Been Tested?

Verified end-to-end with a built binary on a project containing a [system-requirements] table and a v6 lock file:

• pixi run hello and pixi task list: no warnings, and run leaves the v6 lock file untouched.
• pixi workspace channel list and pixi lock: show the deprecation diagnostic; pixi lock upgrades the lock file to v7.

cargo check, cargo clippy, and the pixi_manifest/pixi_core unit test suites pass (the two failing pixi_core tests are pre-existing env-var races that also fail on a clean tree).

Checklist:

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation

🤖 Generated with Claude Code

https://claude.ai/code/session_01RkisJKP8uDL9tseG1udeST

[Hofer-Julian]

For what it's worth, I prefer the current behaviour

[wolfv]

It's really too much I think for established projects. Not everyone is at liberty to update Pixi projects... some are pure consumers.

[Hofer-Julian]

It's really too much I think for established projects. Not everyone is at liberty to update Pixi projects... some are pure consumers.

But isn't it for those also pretty common to pin pixi versions?

I would prefer a pixi migrate command like we have for rattler-build over hiding the warning in most situations.

[wolfv]

If you manage 60 machines with 50 projects and you want to update Pixi to get some bug fixes but you don't have time to update all machines and Pixi projects ... or you have students that have more random versions of Pixi ...

[Hofer-Julian]

I do see your point but this really goes too far for me. We can never actually remove deprecations if we show them so seldomly.

What we could do instead is to stop showing it with pixi run if the environment is already installed.

That way you should still get rid of most of the annoyance while showing them at least once for example in CI.