Problem description

In this example, I expect to always use package-b from source, but with the current setup it will not be used from source in the build of package-a:

pixi.toml

[dependencies]
package-a = { git = "git@git/a.git"}
package-b = { path = "src/b"}

src/a/pixi.toml

[package.build-dependencies]
package-b = "*" # or a version

[patch]

I'm not sure if we should just have this behavior to be automatically resolved, or we should build something like cargo's patch functionality.

This is currently a huge UX problem for the ROS workflow as you can have workspaces with 1 to 40 source dependencies and want to be able to switch back and forward with ease.

Proposed solution:

Adding a patch or overrides table which would work similar to the cargo patch table.

The content of this table is a map of package_name to PixiSpec.

Before Pixi solves any environment, it replaces the PixiSpec of that package_name with the "new" spec. The satisfiability has to take this "new" spec into account.

[overrides]
# Support full PixiSpec
ros-humble-navigator-py = { path = "src/navigator_py" }
ros-humble-my-pkg = { git = "https://github.com/user/my_pkg" }
python = "==3.12.12"
[feature.test.overrides]
ros-humble-talker-py = { path = "src/talker-py" }
[target.linux.overrides]
sdl_example = { path = "src/cpp-sdl" }

This will potentially introduce duplicate definition of a package, this seems acceptable to us. People might create tools around this to make this addition easy through the CLI.

Open questions:

• What about pypi overrides? (maybe [pypi-overrides])
• Are we using patch or overrides/overwrites, blirkblork