cannot use two versions of native dependency in same workspace

[jobafr]

Problem

It seems two binaries inside a workspace cannot have different versions of a dependency linking to a system library. I ran into this when trying to gradually upgrade my workspace to a new version of PyO3.

Technically, I don't think there is a reason why this shouldn't work, since it does work when I move the package out of the workspace.

It seems other people have run into this before, but I couldn't find an exact Github issue for this, so I'm opening one.

Steps

Shell commands / output to reproduce the issue:

me@localhost /tmp/ws $ echo -e "[workspace]\nresolver = \"2\"" > Cargo.toml
me@localhost /tmp/ws $ cargo new a
    Creating binary (application) `a` package
      Adding `a` as member of workspace at `/tmp/ws`
note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
me@localhost /tmp/ws $ cargo new b
    Creating binary (application) `b` package
      Adding `b` as member of workspace at `/tmp/ws`
note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
me@localhost /tmp/ws $ cd b
me@localhost /tmp/ws/b $ cargo add pyo3
    Updating crates.io index
      Adding pyo3 v0.25.0 to dependencies
             Features:
             + indoc
             + macros
             + pyo3-macros
             + unindent
             40 deactivated features
    Updating crates.io index
     Locking 18 packages to latest compatible versions
      Adding autocfg v1.4.0
      Adding heck v0.5.0
      Adding indoc v2.0.6
      Adding libc v0.2.172
      Adding memoffset v0.9.1
      Adding once_cell v1.21.3
      Adding portable-atomic v1.11.0
      Adding proc-macro2 v1.0.95
      Adding pyo3 v0.25.0
      Adding pyo3-build-config v0.25.0
      Adding pyo3-ffi v0.25.0
      Adding pyo3-macros v0.25.0
      Adding pyo3-macros-backend v0.25.0
      Adding quote v1.0.40
      Adding syn v2.0.101
      Adding target-lexicon v0.13.2
      Adding unicode-ident v1.0.18
      Adding unindent v0.2.4
me@localhost /tmp/ws/b $ cd ../a
me@localhost /tmp/ws/a $ cargo add pyo3@0.18.2
    Updating crates.io index
      Adding pyo3 v0.18.2 to dependencies
             Features:
             + indoc
             + macros
             + pyo3-macros
             + unindent
             - abi3
             - abi3-py310
             - abi3-py311
             - abi3-py37
             - abi3-py38
             - abi3-py39
             - anyhow
             - auto-initialize
             - chrono
             - experimental-inspect
             - extension-module
             - eyre
             - full
             - generate-import-lib
             - hashbrown
             - indexmap
             - inventory
             - multiple-pymethods
             - nightly
             - num-bigint
             - num-complex
             - serde
    Updating crates.io index
error: failed to select a version for `pyo3-ffi`.
    ... required by package `pyo3 v0.18.2`
    ... which satisfies dependency `pyo3 = "^0.18.2"` of package `a v0.1.0 (/tmp/ws/a)`
versions that meet the requirements `=0.18.2` are: 0.18.2

the package `pyo3-ffi` links to the native library `python`, but it conflicts with a previous package which links to `python` as well:
package `pyo3-ffi v0.25.0`
    ... which satisfies dependency `pyo3-ffi = "=0.25.0"` of package `pyo3 v0.25.0`
    ... which satisfies dependency `pyo3 = "^0.25.0"` of package `b v0.1.0 (/tmp/ws/b)`
Only one package in the dependency graph may specify the same links value. This helps ensure that only one copy of a native library is linked in the final binary. Try to adjust your dependencies so that only one package uses the `links = "python"` value. For more information, see https://doc.rust-lang.org/cargo/reference/resolver.html#links.

failed to select a version for `pyo3-ffi` which could resolve this conflict
me@localhost /tmp/ws/a $ 

Possible Solution(s)

not using a workspace

Notes

No response

Version

$ cargo --version
cargo 1.86.0 (adf9b6ad1 2025-02-28)

[weihanglo]

Thanks for the issue report!

#5969 seems pretty relevant, though for this case it is because Cargo.lock is a workspace level stuff. Cargo is a bit too restricted when ensuring only one instance of links be in a Cargo.lock (which is the result of dependency resolution), even two workspace members likind completely unrelated. There might be rooms to relax it.

cc @Eh2406 if you're interested in this.