Swift Packages and Conflicting Dependencies

Swift packages and conflicting dependencies

Short answer:

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.

Long answer:

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:

• Now: Option 2 - fail to build.
• Future: Option 3 - install both versions independently

How to use other swift packages in an own swift package?

As previous mentioned, you have to set the dependencies "Alamofire" and "Sodium" to the target. For example:

.target(
   name: "SpaceCryptography",
   dependencies: ["Alamofire", "Sodium"]),

I recommend to also give names to the dependencies packages defined above:

dependencies: [
        // Dependencies declare other packages that this package depends on.
        // .package(url: /* package url */, from: "1.0.0"),
        .package(name: "Sodium", url: "https://github.com/jedisct1/swift-sodium.git", .upToNextMajor(from: "0.9.1")),
        .package(name: "Alamofire" url: "https://github.com/Alamofire/Alamofire.git", .upToNextMajor(from: "5.5.0"))
    ]

How to manage dependencies' conflicts between a framework that I'm making and the main app?

You could do a combination of the two ideas you suggested:

Don't include the other SDKs directly in your framework, but have them in the same project when the user downloads it. That way, if the user doesn't already have them, they can copy over all of the frameworks that they need. And if the user does already have them, then they can just copy your SDK by itself and have it just work in their project.

This combination also allows you to include tests and samples in the download. Then users end up downloading a complete, functioning project that they can try out before integrating it with their own code.

---

Related Topics