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

issue_local_pkg.zip

1. Run the task with a package from a channel on prefix.dev.
   First go into the main-pkg folder.
   Run pixi run mainapp command. The output shows :

Hello from main!
Hello from local package!

2. Switch to use the local version of the package
   Then, comment the line local-build-local-pkg = ">=0.1.0, <1.0.0" and uncomment local-build-local-pkg = { path = "../local-pkg" } in host and run sections
   Re run pixi run mainapp. The local package is now built from the local path but the pixi.lock still uses the package from prefix.dev and the output shows :

Hello from main!
Hello from local package!

instead of

Hello from main!
Hello with error from local package!

Issue description

This issue might be related to #4844.

When building a package that initially depends on another package hosted on prefix.dev, then switching to a local version of that same dependency, the pixi.lock file is not updated correctly. As a result, Pixi continues to use the cached package from prefix.dev instead of the newly built local package.

Expected behavior

Expected Behavior

Pixi should detect that the dependency source has changed (from remote to local) and update pixi.lock accordingly so that the local package is used.

Actual Behavior

The pixi.lock file keeps referencing the remote package, leading Pixi to use the cached version instead of the local build.

Steps to Reproduce

1. Add a package dependency coming from prefix.dev into the main pixi.toml.

2. Build your main package.

3. Replace the dependency with a local version using a local path.

4. Rebuild and run the project.

5. Observe that Pixi still uses the cached prefix.dev version.

Workaround

The only workaround I’ve found so far is to manually delete the pixi.lock file and the rerun the task or project

This forces Pixi to regenerate pixi.lock with the correct local dependency.