Как создать PocSpec CocoaPods, который имеет зависимость, которая существует вне Specs?

У меня есть общедоступная форма библиотеки, которая уже существует в CocoaPods/Specs. В подфайле я могу ссылаться на этот разветвленный блок, выполнив следующее:

pod 'CoolLibrary', :git => '[email protected]:myname/CoolLibrary-Forked.git', :commit => 'abcdef1234567890abcdef1234567890'

Я попытался поместить это в свой MyLibrary.podspec:

s.dependency 'CoolLibrary', :git => '[email protected]:myname/CoolLibrary-Forked.git', :commit => 'abcdef1234567890abcdef1234567890'

Но получите следующее сообщение об ошибке:

-> 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.

Можно ли указать зависимость в .podspec таким образом (то есть для пакета, который имеет подспец, но который не находится в CocoaPods/Specs)?

Ответы

Ответ 1

Это не разрешено с помощью podspecs, так как это позволяет сделать невозможным для других podspecs определить, какой пакет они зависят и/или другие пакеты могут сломаться из-за неожиданных различий API.

Например, рассмотрите два модуля, зависящих от AFNetworking, но один указывает внешнее местоположение источника (Pod A), в то время как другое указывает только требования к минимальной версии (Pod B):

  • Pod A: s.dependency 'AFNetworking', :git => 'https://arbitrary/location'
  • Pod B: s.dependency 'AFNetworking', '> 2'

Теперь есть несколько потенциальных проблем:

  • На данный момент мы не знаем, какая версия находится в репозитории Pod A, пока мы ее не загрузим, что представляет собой огромную трату времени, если не будут удовлетворены различные общие зависимости от AFNetworking (например, Pod B).
  • Но что еще хуже, если "Pod A" соответствует требованиям к версиям зависимостей других модулей (например, "Pod B" ), но код AFNetworking на самом деле находится из раздвоенного исходного местоположения, и он изменяет некоторые существенные API, которые зависят от Pod B, Это будет тихо нарушать обещание, которое CocoaPods пытается сделать.

Надеюсь, это даёт понять, почему мы не можем ввести способ, чтобы podspecs молча нарушил версию promises. Тем не менее, из вашего подфайла вы можете переопределить местоположение исходного кода, поскольку он является конечным пользователем (разработчиком приложения), который находится под контролем, и не должно быть никаких неожиданных сбоев.

Ответ 2

Зависимости очень просты, имея только возможность определять имя и спецификатор версии Pod. Они не могут быть расширены с теми же расширениями, что и зависимость в подфайле.