Two third party packages share the same name

[wheelius (Will Morris)]

Currently working with my team to bring our Pods dependencies over to SPM. We have an internal local package (will reference this as 'MyPackage') that depends on the Optimizely swift-sdk package (https://github.com/optimizely/swift-sdk). We also have a dependency on the Iterable swift-sdk package (GitHub - Iterable/swift-sdk: Iterable's iOS SDK. Receive and track pushes to Iterable from your iOS app.). When trying to resolve the packages, we get this warning:

> 'MyPackage' dependency on 'https://github.com/optimizely/swift-sdk' conflicts with dependency on 'https://github.com/iterable/swift-sdk' which has the same identity 'swift-sdk'. this will be escalated to an error in future versions of SwiftPM.

We also get this error:

Failed to resolve dependencies Dependencies could not be resolved because 'MyPackage' depends on 'swift-sdk' 3.7.0 and root depends on 'swift-sdk' 6.0.0..<7.0.0.

For the error, the first 'swift-sdk' that is 3.7.0 is the Optimizely package, while the latter is the Iterable package. How can this be solved? Is there a way to specify these are different packages?

edit: 'MyPackage' has the dependency on Optimizely, while the core project has it for Iterable. So it should look like 'Core Project' -> 'MyPackage' -> 'Optimizely' and 'Core Project' -> 'Iterable'

[NeoNacho (Boris Buegling)]

It is not possible to use two packages with the same identity in a single package graph.

[wheelius (Will Morris)]

Is there a workaround for this flaw? Or do we need to wait for a fix?

[taylorswift]

how could the SPM possibly distinguish between the two packages, if they share the same name?

[wheelius (Will Morris)]

I'd like to note that these Packages have different names. 'IterableSDK' and 'Optimizely'. The only thing they share is the end path component of 'swift-sdk'. Why is the package graph relying on the end path component rather than the whole url for its identity? Or not using the Package name as identity? Perhaps I'm not understanding something or doing the setup wrong?

[wheelius (Will Morris)]

Here is a screenshot of the Iterable package in our project settings. As seen the name of the package is 'swift-sdk'. However, when looking at the 'Package.swift' file, the name is 'IterableSDK' (swift-sdk/Package.swift at master · Iterable/swift-sdk · GitHub).

And here is us trying to add the 'Optimizely' package. As seen again, the name is set to 'swift-sdk' by SPM even though the name in the 'Package.swift' file is 'Optimizely' (swift-sdk/Package.swift at master · optimizely/swift-sdk · GitHub)

Notice the error at the bottom saying the project already contains the package.

[xwu (Xiaodi Wu)]

SwiftPM uses the last path component of URL as the "identity"; an option to specify explicit dependency names in SE-0226 was rolled back in an amendment due to user confusion.

The reason for not using the package name for package identity was outlined in an amendment to SE-0292, which considered its use as part of a registry service, as follows:

1. It burdens the registry with a requirement to invoke the Swift toolchain to parse the Package manifest
2. It creates competing sources of truth between the {name} parameter in the HTTP request and the declared name
3. It causes confusion among package consumers and maintainers, who may not be aware of the package's declared name, nor understand the distinction between that and the source repository name
   We now propose to migrate existing packages according to their repository name, and have updated the naming rules accordingly. Notably, the use of dashes (-) are now supported.

The core team returned SE-0292 for further discussion about package identifiers, but near as I can tell this discussion never reached a resolution as the proposal authors strongly objected to the core team decision. Based on the links in the proposal, no revision of package identifiers along the lines proposed in SE-0292 ever landed.

[wheelius (Will Morris)]

Thank you for this insight and the links. I'll be sure to keep an eye out for future discussions around this.