SwiftPM Conflict between dependencies that are not sharing a target?

Using Swift
1

Hi all,

Shouldn't dependencies that are not included in the same target not conflict? I have getting a dependency resolution error here that I don't understand.

// swift-tools-version:5.2
// The swift-tools-version declares the minimum version of Swift required to build this package.

    import PackageDescription

    let package = Package(
    name: "SwiftPMTest",
    products: [
        .library(
            name: "SwiftPMTest",
            targets: ["SwiftPMTest"]),
    ],
    dependencies: [
        .package(url: "https://github.com/IBDecodable/IBLinter.git", from: "0.4.23"),
        .package(url: "https://github.com/realm/SwiftLint.git", from: "0.39.2")
    ],
    targets: [
        .target(
            name: "SwiftPMTest",
            dependencies: []),
        .testTarget(
            name: "SwiftPMTestTests",
            dependencies: ["SwiftPMTest"]),
    ]
)

The error I get is:

because SwiftLint >=0.37.0 depends on Commandant 0.17.0..<0.18.0 and IBLinter 0.4.23 depends on Commandant 0.16.0..<0.17.0, SwiftLint is incompatible with IBLinter.
And because no versions of IBLinter match the requirement 0.4.24..<1.0.0, SwiftLint is incompatible with IBLinter.
And because root depends on IBLinter 0.4.23..<1.0.0 and root depends on SwiftLint 0.39.2..<1.0.0, version solving failed.

Makes sense.. they both depend on incompatible versions of Commandant , sure, but if you take a look at the targets I'm not actually including either in the dependencies array. I must be misunderstanding something here...

2

The current model considers everything to be in a single unified graph, so this is not a bug. It is, however, a reasonable feature request.

If the completion of SEā€0226 gets merged in its current state, your manifest would become valid. swift build would fetch both packages but none of their dependencies, sidestepping the conflict. swift run swiftlint would reā€resolve and succeed, and swift run iblinter would reā€resolve again and also succeed. Since there is still only one graph cache, going back and forth would be slow, but at least it would work.

But donā€™t hold your breath. Itā€™s not the main purpose of that PR, just a sideā€effect. So it could end up taking a different form by the time it is actually part of a release.

An officially supported way to do what youā€™re trying to do would likely come later on.

3

Gotcha. Thank you, @SDGGiesbrecht . Best of luck with the PR! Iā€™ll keep an eye on that aspect of the feature. I think others will probably come across this issue too if they manage multiple targets or like in my example, try to manage several command line tools through SwiftPM.

4

hey @SDGGiesbrecht what was the verdict on this? I saw the PR was merged, but you mentioned that what I'm looking for is not the main purpose of the PR and that it may change. Will I be able to accomplish this in 5.3?

5

That PR was merged into master, but hasnā€™t (and likely wonā€™t be) cherryā€picked into the 5.3 branch. I assume it will automatically end up in a future 5.4 branch, and you can check the pattern of release history to speculate on when that will be released.

A feature that formalizes this sort of tool management would need to go through the evolution process, so keep your eye on the forums and share your thoughts if a proposal appears.

Until formalization, it will most likely remain the way I described earlier. However, I still advise treating the graphā€splitting side effect the way you would an underscored symbol; it does its job reliably at the moment, so itā€™s fine to use as a development tool, but it could change at any time, so donā€™t release anything that depends on its continued stability.

1 Like