Possible issue with nested dependencies not being properly resolved

[CatalinM (Catalin Mustata)]

I've recently had an issue with SPM not being able to resolve the dependency graph, complaining that a framework (of my own design) used in my Xcode iOS app project contains an incompatible dependency.

**Showing All Messages**

: the package ...[...] @ 0.7.0 contains incompatible dependencies:

ohhttpstubs[https://github.com/AliSoftware/OHHTTPStubs.git] @ feature/spm-support

Besides the very cryptic message (ohhttpstubs doesn't have dependencies, so it can't clash with anything I already had in the app, while already working in the framework by itself), I couldn't find any other info. Also, it seemed strange that both my app and my framework depended on Alamofire and SPM managed to resolve that without hiccups.

As a Hail Mary sort of thing, I tried removing the Package.resolved file from my framework... and all problems went away. Still, this feels as a bug.

Bonus question: would it be possible to somehow exclude the dependencies of test targets defined by other dependencies from the final resolved tree? At first thought it wouldn't make much sense to have those in an app since you won't use then in your app build.

EDIT: Deleting Package.resolved worked when using the framework as a local package, but when switching back to the hosted repo, it still fails with the same error. Very strange.

[SDGGiesbrecht (Jeremy David Giesbrecht)]

@CatalinM

@ 0.7.0 contains incompatible dependencies: ohhttpstubs[GitHub - AliSoftware/OHHTTPStubs: Stub your network requests easily! Test your apps with fake network data and custom response time, response code and headers!] @ feature/spm-support

That looks like a tagged version (0.7.0 of [whatever you redacted]) depends on a branch (feature/spm-support of OHHTTPStubs). It is illegal for tagged versions to depend on branches.

@CatalinM

Bonus question: would it be possible to somehow exclude the dependencies of test targets defined by other dependencies from the final resolved tree? At first thought it wouldn't make much sense to have those in an app since you won't use then in your app build.

That is SE‐0226, which was accepted. It’s just not available yet.

[CatalinM (Catalin Mustata)]

Ah well, looking back it makes a lot of sense. The vague error message threw me off though... this really needs some improvement.

Out of curiosity, how long does it usually take for such an improvement (SE-0226) to reach production?

Anyways, thanks for the help Jeremy!

[SDGGiesbrecht (Jeremy David Giesbrecht)]

Most proposals land much faster than SE‐0226.

This one is slow coming because the internal design of the resolver is being completely replaced to improve both speed and the quality of diagnostic messages. Both resolvers are available in the current toolchain. Implementing SE‐0226 now would mean implementing it double. (Edit: This is an outsider’s attempt at mind reading. The actual developers may have other reasons.)

You can try out the experimental new resolver with --enable-pubgrub-resolver. It isn’t ready to replace the old one completely yet, but it tends to have much better error messages wherever it does work. So whenever an error message isn’t clear, try the same operation with the other resolver.