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

I created a new project like this pixi init . --format pyproject and adjusted the pyproject.toml to look like this

[project]
dependencies = []
name = "foobar"
requires-python = ">= 3.14"
version = "0.1.0"

[build-system]
build-backend = "hatchling.build"
requires = ["hatchling"]

[tool.pixi.workspace]
channels = ["conda-forge"]
platforms = ["osx-arm64", "linux-64", "win-64"]

[tool.pixi.pypi-options]
no-build = true

[tool.pixi.pypi-dependencies]
foobar = { path = ".", editable = true }

where basically only no-build = true has been added.

Then I run pixi install once to create the lock file and the run pixi install --locked to verify that the lock file works but then I get this error (with verbose logs)

INFO pixi_core::lock_file::outdated: environment 'default' is out of date because the lock-file contains non-binary package: 'playground', but the pypi-option `no-build` is set
Error:   × lock-file not up-to-date with the workspace

Issue description

It seems like no-build = true clashing with having a local editable install of the project itself but setting no-build = true is important for my use case because I need to ensure that all my PyPI dependencies have wheels for all the platforms I care about. I want to avoid sdists.

This is just a small example to reproduce the issue but I actually have a monorepo with many Python packages of which some depend on each other and my services use them as local editable installs. But the problem is the same.

Also, I was using no-build = true for a long time and it wasn't a problem until I upgraded to the latest pixi version (0.64.0). I think the version I used before was 0.59.0 and it was fine.

Expected behavior

pixi install --locked should work without error.