How do I create a CocoaPods podspec that has a dependency that exists outside of Specs?
I have a public fork of a library that already exists in CocoaPods/Specs. In a Podfile, I can reference this forked pod by doing this:
pod 'CoolLibrary', :git => '[email protected]:myname/CoolLibrary-Forked.git', :commit => 'abcdef1234567890abcdef1234567890'
I tried putting this in my MyLibrary.podspec:
s.dependency 'CoolLibrary', :git => '[email protected]:myname/CoolLibrary-Forked.git', :commit => 'abcdef1234567890abcdef1234567890'
But get the following error message:
-> MyLibrary.podspec
- ERROR | The specification defined in `MyLibrary.podspec` could not be loaded.
[!] Invalid `MyLibrary.podspec` file: [!] Unsupported version requirements. Updating CocoaPods might fix the issue.
Is it possible to specify a dependency in a .podspec in this way (i.e. for a pod that has a podspec, but which isn't in CocoaPods/Specs)?
Answer
This is not allowed from podspecs, because allowing so would make it next to impossible for other podspecs to define what package they depend on and/or other packages could break because of unexpected API differences.
For instance, consider two pods that depend on AFNetworking, but one specifies an external source location (Pod A) while the other only specifies a minimum version requirement (Pod B):
- Pod A:
s.dependency 'AFNetworking', :git => 'https://arbitrary/location' - Pod B:
s.dependency 'AFNetworking', '> 2'
Now there are a couple of potential problems:
- At this point we have no idea what version is in the ‘Pod A’ repo until we download it, which is a massive waste of time in case the various common dependencies on AFNetworking (e.g. ’Pod B’) can’t be satisfied.
- But what’s even worse is if ‘Pod A’ does match the dependency version requirement of other pods (e.g. ‘Pod B’), but the AFNetworking code is actually from a forked source location and it changes some essential API that ’Pod B’ depends on. This will silently break the promise that CocoaPods tries to make.
I hope this makes it clear why we cannot introduce a way for podspecs to silently break the version promises. However, from your Podfile you are allowed to override any pod’s source location, because it is the end-user (the app developer) who is in control and there should not be any unexpected breakage.