Pod version resolution issue when both Podfile and pod depend on different versions of same dependency

[phatblat]

I've found a very subtle yet potentially serious issue where the version of a dependency is miscalculated or multiple copies of the dependency are installed.

Note that I assume this is an issue in Core based on my guess of how the various CocoaPods repos depend on each other. Let me know if this issue is mis-filed and I will happily recreate in the correct repo.

---

This issue originally arose when my app's Podfile depended on a loose (~> 2.0) version of an AFNetworking subspec. Two pods called out in the Podfile also depended on loose versions of AFNetworking subspecs. When I ran pod install on 2/26 (when 2.2 was released), I ended up with both 2.1.0 and 2.2.0 versions of AFNetworking installed on top of each other, causing compiler issues.

I've since determined that whether the Podfile specifies a dependency on the subspec or the top-level spec does not matter. The version of the dependency in the Podfile also doesn't matter much since even pinning it to a specific version (= 2.1.0) causes the issues. What matters is the (shared) dependency declaration in the referenced podspec.

Issue Cases

1. Two different versions of a shared dependency installed
2. The latest version of a shared dependency installed, despite the Podfile forbidding it with version pinning

Conditions

• Pod which depends on the shared dependency must appear before it in the Podfile
• Pod which depends on the shared dependency must have a name string sorted after it (install progress shows in this order)
• .podspec
  • If pod depends on a subspec of the shared dependency, both the Podspec-pinned version and the latest version of it will be installed (Issue case 1 above).
  • If pod depends on the top-level spec of the shared dependency, only the latest version of it will be installed (Issue case 2 above).

shared dependency == AFNetworking

---

I've created a project which reproduces these issues at https://github.com/phatblat/SubspecUpdateIssue. Toggle the AFNetworking dependency lines in ZPodUsingAFN.podspec between the subspec and the top-level spec and run pod install to witness the above 2 issue cases.

If someone gives me some pointers on the pertinent details I might be able to include them in an example at https://github.com/CocoaPods/cocoapods-integration-specs/.

---

Reproducing the case where pod install upgrades a pod it shouldn't have with a fuzzy version spec (~> 2.0) is harder to reproduce as it requires a Podfile.lock created while the offending version didn't exist. However, I believe the above cases are enough to resolve the current issue since it's reproducible with a pinned version in the Podfile.

[sharplet]

I've seen the same behaviour. Unfortunately I can't provide any more detail to the reproduction steps here, however I just want to note that in my case the issue is resolved by running pod update. That is, 1) I run pod install, 2) I compile and notice linker errors (duplicate symbols), and 3) I run pod update which removes the duplicate activated pod version.

[phatblat]

I also was able to work around this issue with a 'pod update' and the loose ~> 2.0 pod dependency in my Podfile. This is why this issue was so hard to grasp.

I ran 'pod install' because I had added a new, unrelated pod to the Podfile and got two versions of AFNetworking installed and the compiler errors. In chasing down the errors I ran 'pod update', which ignored the Podfile.lock and upgraded to AFNetworking to 2.2.0 since my original Podfile specified a loose 2.0 dependency. Then no errors.

I wasn't satisfied with simply working around these errors and hence created this issue.

[fabiopelosin]

This issue should be moved to CocoaPods, @phatblat can you do it?

[fabiopelosin]

Moved to CocoaPods/CocoaPods#2002

[phatblat]

Thanks @irrationalfab.

[fabiopelosin]

🍻

[Varsha-Kulkarni]

I'm facing these issues yet!
Analyzing dependencies
[!] Unable to satisfy the following requirements:

• AFNetworking (= 1.3.4) required by Podfile.lock
• AFNetworking (~> 1.3.0) required by RestKit/Network (0.20.3)
• AFNetworking (~> 2.5) required by ABMSoundCloudAPI (0.1.0)

[orta]

@VarshaSameer those dependencies cannot be resolved at all, as you cannot have two versions of the same library in the same codebase.

[Varsha-Kulkarni]

So what would be the solution suggested? Can we actually fork those repos and then change the dependencies within the podfiles?

[orta]

You can do that, but they have different APIs, and RestKit is eventually planning on removing AFNetworking which would fix that. For now, you should fork ABMSoundCloudAPI and make it work with AFNetworking 1.x. Probably way easier than the other way around.

[rijieli]

I am facing the following issue:

I do not want to upgrade the library version for the iOS project, but for visionOS, this library needs to be upgraded to the newest version.