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

Given the following pyproject.toml:

[project]
name = "minimal_project"
version = "0.1"
description = "just says hello"
requires_python = ">=3.11"

[build-system]
requires = ["flit_core>=3.2,<4"]
build-backend = "flit_core.buildapi"

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

# Use the project in editable for development
[tool.pixi.feature.dev.pypi-dependencies]
minimal_project = { path = ".", editable = true}

# Don't install in editable mode for production
[tool.pixi.feature.prod.pypi-dependencies]
minimal_project = { path = ".", editable = false}

[tool.pixi.environments]
# We want to use the same solve-group for solving
# the same set of dependencies and we would only
# need to do this once
default = {features = ["dev"], solve-group = "default"}
prod = {features = ["prod"], solve-group = "default"}

Minimal project is just a simple example project, see the pixi/examples/pypi-source-deps for the module.

We have a case that @pavelzw has a lot, where we want to install a dependency as editable in development and non-editable in production. But do need to use the same solve-group so we use the same set of dependencies everywhere.

Currently running this will create both editables for development and production.

pixi list -e prod
Package          Version       Build               Size       Kind   Source
...
libzlib          1.2.13        h53f4e23_5          47 KiB     conda  libzlib-1.2.13-h53f4e23_5.conda
minimal_project  0.1                                          pypi   . (editable)
ncurses          6.4.20240210  h078ce10_0          801 KiB    conda  ncurses-6.4.20240210-h078ce10_0.conda
...

Removing the solve-group solves this.

pixi list -e prod
Package          Version       Build               Size       Kind   Source
...
libzlib          1.2.13        h53f4e23_5          47 KiB     conda  libzlib-1.2.13-h53f4e23_5.conda
minimal_project  0.1                                          pypi   . 
ncurses          6.4.20240210  h078ce10_0          801 KiB    conda  ncurses-6.4.20240210-h078ce10_0.conda
...

Issue description

So removing the solve-group solves the issue but is generally not what you want. What we want is to solve once and install in two different ways, this requires building two seperate wheels. Editable wheels are different from regular ones. But because we need to resolve an source essentially we need to build the metadata first in the resolution phase.

So there are two problems:

1. Using the same solve-group incorrectly marks the dependency as editable in the prod installation.
2. PEP517 defines a hook: prepare_metadata_for_build_wheel and PEP662 defines a hook prepare_metadata_for_build_editable, for which there are no guarantees that they produce the same metadata. Actually, we know they don't produce the same .dist-info folder for sure (missing RECORD amongst other things)

We just need to debug 1) to see whats going wrong.
However, for 2) we need to assume that the hooks create the same METADATA file for now. It's the only way to allow this feature to work. I currently see no reason why it shouldn't generate the same METADATA but I don't know all the build backends internals or projects that might do something that produces different METADATA. So if anyone can enlighten me please!

Expected behavior

This should create two environments a default one with the editable install and a prod one where the installation is not editable.