The evolution proposal for Module Aliasing for Disambiguation has this as it's second bullet point in the Motivation section:
Two different versions of the same package need to be included in the same program. Programmers often run into this problem when trying to upgrade a dependency that another library has pinned to a specific version. Being unable to resolve this collision makes it difficult to gradually update dependencies, forcing migration to be done all at once later.
The remainder of the evolution document focuses on resolving two different dependencies (from different repositories or local paths) with the same name, and doesn't mention versioning again. The proposal is marked as implemented in Swift v5.7.
I'm trying to make use of this functionality in, I think, the intended fashion for the versioning case but can't seem to make it work. I've boiled it down to a very simple example.
I have two library packages (named "first" and "second" respectively) that each bring in a remote dependency, let's call it "remote_thing". One of the packages uses remote_thing with from: "2.0.0", and the other uses remote_thing with from: "3.0.0". Note this all works fine for the individual "first" and "second" packages. My executable target wants to use both of these libraries to do it's work.
If I just use dependencies: ["first", "second"] in the app, Swift correctly complains:
error: Dependencies could not be resolved because 'first' depends on 'remote_thing' 2.0.0..<3.0.0 and 'second' depends on 'remote_thing' 3.0.0..<4.0.0.
moduleAliases to the rescue, I thought. But when I tried this I got the exact same error.
dependencies: [
"first",
.product(name: "second", package: "second", moduleAliases:["remote_thing": "second_remote_thing"])
]
Should it be possible to use moduleAliases in this way?
I can post complete Package.swift files if anybody is interested in reproducing locally.