Whats New with Lockfile Version 7

"Lockfile v7" landed in Pixi on 2026-05-01 (PR #5607) and got a string of follow-up fixes and features over the next week. This changes the version number written into lock files generated by Pixi. Such a lock file bump causes friction, the Pixi team only does it when it unlocks something users have actually been asking for: And indeed, the change allowed us to close several long-standing feature requests and bugs. So what is in it for you?

Upgrading is a one-time step

After upgrading Pixi, the first run that needs to refresh dependencies will rewrite your lock file from version: 6 to version: 7. There is nothing to migrate by hand, but older Pixi versions cannot read a version 7 lock files, so coordinate the upgrade with collaborators and CI before merging the regenerated pixi.lock. Note that pixi will try hard to leave an older lock file unchanged as long as possible! Use pixi lock to force an update.

Build environments are now locked

If your workspace has path = "...", git = "...", or other source dependencies that go through a build backend, then you will see reproducible builds. The build and host environments the build backends resolve are now recorded in the lock file alongside the runtime environment. In version 6 only the run-time packages were stored; the build/host environments were re-resolved on every machine and at every install What this means in practice:

• Reproducible builds across machines. Once pixi.lock is committed, your collaborator and CI build against the exact same compiler version, the exact same headers, the exact same build-time tools you did. No more "works on my laptop, fails on the CI runner" because conda-forge published a new GCC overnight.

• Faster installs of source packages. The build/host envs no longer need to be re-resolved as Pixi reads them straight from the lock file.

• --locked semantics for source packages. Previously pixi install --locked could only check the run packages; the build environment was free to drift. Now --locked verifies the build environment too. When Pixi opens a version 6 lock file and needs the build/host packages, it recomputes them once during the upgrade. After that, the version 7 lock file carries them.

Less lock file churn

This is a big one for all users: We store less volatile information, so you will end up with fewer commits containing your lock file.

Source-code edits no longer rewrite the lock file

In version 6, comment-only edits to a pyproject.toml could be enough to mark the lock file out of date, because Pixi hashed source-tree inputs into the lock file itself. Version 7 removes those input hashes entirely. Editing a comment, formatting a manifest, or touching unrelated files in your project no longer churns pixi.lock. Only changes that actually affect the resolved environment do.

pypi-prerelease-mode only appears when it's used

If your project does not use any PyPI dependencies, Pixi no longer serializes pypi-prerelease-mode: if-necessary-or-explicit into the lock file options block. Conda-only workspaces stay PyPI-free in their lock file too -- which matters in restricted environments where reaching out to pypi.org is undesirable. (Closes #5130) editable is no longer redundant in the lock file

You can now mix editable and non-editable PyPI source dependencies inside the same solve group. The redundant flag was removed from the lock file representation.

More portable lock files

Another big issue many users faced: Absolute paths in the lock file. This broke sharing lock files across machines and CI.

Relative paths stay relative

Previously, when uv canonicalized a path = "my_subdir" PyPI source entry it would write the absolute file:///home/you/... URL into pixi.lock. That broke sharing the lock file across machines and CI. Version 7 preserves the verbatim, relative spelling.

Symlinks are no longer resolved

If you have a symlinked dependency (e.g. my_lib = { path = "./my_lib", editable = true } where my_lib is a symlink to ../my_lib), version 6 stored the resolved target ../my_lib) into the lock file, which then failed pixi install --locked on any machine where the symlink target wasn't in the same place -- a Docker build being the classic example. Version 7 keeps the spelled path.

Fewer false "lock-file not up-to-date" errors

Several long-standing situations where pixi lock && pixi install --locked would fail back-to-back are now fixed:

1. Workspaces with many environments and solve groups. The original report (#5256) was a numba-cuda manifest with dozens of CUDA × Python environments. pixi lock would happily write a lock file that the very next --locked install rejected. Version 7 makes the resolution and the satisfiability check agree.

2. Projects that compose extras (e.g. all = ["pkg[a]", "pkg[b]"]). uv leaves these self-references intact, while build backends like hatchling expand them in wheel metadata. The two views compared as different and triggered a spurious "lock-file not up-to-date" on every install. Version 7 expands the self-references during the satisfiability check, with cycles broken on the path that closes them.

3. Cross-platform locking on a host that's not in the lock file. If you locked for Linux only and ran pixi install on macOS arm64, the satisfiability check could hit a code path that needed Python in the host conda prefix and crashed with a PythonMissingError. The fallback that required it has been dropped.

4. Transitive git dependencies declared in pyproject.toml when the workspace also has a pixi.toml. The git ref was not recorded for transitive deps, which then made pixi install --locked reject what pixi update had just produced.

5. Transitive PyPI dependencies of packages from a custom index. Their parsed PEP 508 form has no concept of an index, which the version 7 check initially read as "user wants the default index" and flagged on every pixi lock. Now the strict index check fires only for direct manifest deps.

Better PyPI cache reuse with custom indices

PyPI installs against a non-default index (private Cloudsmith, Artifactory, a corporate mirror, …) now reliably hit the local uv cache. Before version 7, a hardcoded default-PyPI URL leaked into one of the cache keys, so resolution wrote one entry and installation looked up another. The result was constant re-downloads -- particularly painful inside Docker buildx cache mounts. While in the same area, pixi list now also fills in the Size and Source columns for packages that come from non-default PyPI-style registries.

Should you update?

If you depend on any of the following, absolutely yes:

1. A workspace with PyPI dependencies that compose extras all = ["pkg[a]", "pkg[b]"])

2. A workspace with symlinked or relatively-pathed local PyPI source deps that you share across machines or CI.

3. Builds that go through a non-default PyPI index, particularly inside Docker layers where re-downloading on every build is costly.

If your projects are small and lock cleanly today, the upgrade is uneventful: You'll just stop seeing the rough edges listed above.