One of the most challenging tasks of every package manager I have seen is handling conflicting dependencies.
Let's work with the following imaginary application SwiftApp, which depends on some 3rd party packages.
- SwiftApp
- packageA@latest
- packageC@1.0.0
- packageD@latest
- packageB@latest
- packageC@2.0.0
- packageE@latest
From the dependency graph above, we can see that both of SwiftApp's dependencies use packageC, but with different major version identifiers. For most language ecosystems, this becomes a problem - a major version bump usually means there have been made changes to the code which are not backwards-compatible with the previous major version.
Depending on technical capabilities of the language/compiler/other relevant component, the package manager can be implemented in one of the following ways:
The third option can only be achieved with proper support by the language or compiler itself.
In other words, is it technically possible for packageA to have (and use) version 1.0.0 of packageC while packageB will have version 2.0.0?
Given the recent announcement of Swift being now open-source and coming with a package manager of its own, I think that this question might be very valuable for future readers interested in Swift package development.
Now it's option 2, fail to build.
It gives an error: swift-build: The dependency graph could not be satisfied
It's because SPM is on very early stage of development, very early beta.
Dependency Resolution
The Swift Package Manager does not currently provide a mechanism for automatically resolving conflicts in a dependency tree. However, this will be provided in the future.
Swift has namespaces. It means that packageC in packageA would have a full name packageA.packageC. And in packageB it would be packageB.packageC
Because of that, it is possible to have the same framework included more than once.
SPM also fetch dependencies with version suffix (packageC-1.0.0). So I think It should be possible to check what version is required in particular package and fetch it.
Also Swift supports Dynamic frameworks. It means that you can have many version of the same framework and they should not conflict with each other.
As I see it in the future it should be possible to have Option 3 (Install packageC for both packages independent) working.
Summary: