You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 oncedefault = {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.
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:
Using the same solve-group incorrectly marks the dependency as editable in the prod installation.
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.
The text was updated successfully, but these errors were encountered:
Technically you cannot install a package editable and non-editable at the same time; so it also kind-of makes sense to not allow this... (but it would make like in a docker deployment a bit easier)
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
: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:
prepare_metadata_for_build_wheel
and PEP662 defines a hookprepare_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 sameMETADATA
but I don't know all the build backends internals or projects that might do something that produces differentMETADATA
. So if anyone can enlighten me please!Expected behavior
This should create two environments a
default
one with the editable install and aprod
one where the installation is not editable.The text was updated successfully, but these errors were encountered: