`pixi.lock` always outdated when using local folder with `editable` as `PyPI` dependency

[benglewis]

Checks

• [X] I have checked that this issue has not already been reported.

• [X] I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example

pixi init
pixi add python
pixi add --pypi 'local_pypi_package @ ./local_pypi_package' --editable
pixi install --locked -v

Issue description

INFO pixi::lock_file::outdated: the pypi dependencies of environment 'default' for platform osx-arm64 are out of date because the requirement 'local_pypi_package @ file:///test/local_pypi_package' could not be satisfied (required by '') × lock-file not up-to-date with the project

Expected behavior

No error should be shown

[ruben-arts]

I believe this is the case for pyproject.toml right? This is because we get a hash of the pyproject.toml file to verify if a local package should be reinstalled (Checked for new build logic or dependencies). pixi add or any other manifest editing change invalidates the hash of the file and results in an unsatisfied lock file.

This should indeed be fixed for pixi add here the hash is written after writing to the file instead of before.

[jjjermiah]

@ruben-arts what would be the solution for this?

[tdejager]

The workaround, which is not a solution is to split the project into a pixi.toml and pyproject.toml, with the pyproject.toml containing just the build info.

The solution would be to better detect if the pyproject.toml is still up-to-date. However, this is quite difficult because different tool sections can influence the build process. We now just record a sha of the pyproject.toml and if this changes we resolve and rebuild.