Как работает CocoaPods

Я использовал CocoaPods для некоторых моих проектов. Это круто и легко обновляется с помощью моих зависимостей/фреймворков с открытым исходным кодом.

Но у меня есть некоторые сомнения относительно внутренней работы CocoaPods.

В нашем подпикселе мы даем только имя стручков, иногда версия также, например

pod "AFNetworking" , "1.3.2"

Затем он правильно находит и клонирует репозиторий AFNetworking. Как это работает? Как рубиновые драгоценные камни знают, что фактический репозиторий находится в Гитубе. Являются ли стручки только с Github? (Потому что я видел контейнеры для только фреймворков, доступных на Github). Если мы можем использовать контейнеры для зависимостей, отличные от Github (например, от Bitbuket), как мы можем добавить этот pod в наш Podfile?

ОТВЕТЫ

Ответ 1

CocoaPods делает много за кулисами, чтобы сделать все, что вы говорите о работе. На относительно высоком уровне фактические "под" управляются в репо, который живет на Github здесь. Это то, где сторонние разработчики библиотеки представляют свои "Pods" для работы с CocoaPods. Вы заметите, что если вы ищете Pod с помощью инструмента командной строки с pod search AFNetworking, вы увидите все доступные Pods, соответствующие вашему поисковому запросу.

Что касается Github и других сайтов, даже если репозиторий, полный спецификаций CocoaPods, живет в Github, CocoaPods сам использует просто старый Git, чтобы вытащить источник из данного репозитория. Из-за этого вы можете создавать спецификации из любого репозитория Git, размещенного на любом сайте. Мы также поддерживаем svn, mercurial и просто старые http (ы). Если вам интересно, как работают спецификации, вы можете посмотреть на некоторые из specs repo, вы можете открыть их с ~/.cocoapods/repos/master на своем локальном компьютере или отредактировать напрямую с pod spec edit AFNetworking из командной строки.

Ответ 2

CocoaPods - это инструмент управления зависимостями библиотеки для приложений OS X и iOS. С CocoaPods вы можете определять свои зависимости, называемые модулями, и легко управлять их версиями в течение времени и в разных средах разработки.

CocoaPods реализует подход Implicitly dependency[About] :

Podfile - это файл, который определяет модули, которые вы хотите использовать.
Podspec - это файл, который определяет, как конкретный модуль добавляется в проект.

pod install

  1. Чтение подфайла.
    Итак, первый шаг во время установки - выяснить, какие модули определены как явно, так и неявно. CocoaPods проходит и составляет список всех этих и их версий, загружая podspecs. Podspecs хранятся локально в ~/.cocoapods.

  2. Управление версиями и конфликты.
    CocoaPods использует соглашения, установленные Semantic Versioning, для разрешения версий зависимостей.

  3. Загрузка источников.
    Следующий шаг в процессе - загрузка исходных текстов. Каждый .podspec содержит ссылку на файлы, обычно включая git remote и тег.

  4. Создание Pods.xcodeproj.
    Каждый раз, когда запускается pod install и обнаруживаются изменения, Pods.xcodeproj обновляется с помощью гема Xcodeproj. Если файл не существует, он создается с некоторыми настройками по умолчанию. В противном случае существующие настройки загружаются в память.

  5. Установка библиотек.
    Когда CocoaPods добавляет библиотеку в проект, он добавляет гораздо больше, чем просто источник. Поскольку изменение для каждой библиотеки получает свою собственную цель, для каждой библиотеки добавляется несколько файлов

  6. Запись на диск.
    До сих пор большая часть этой работы выполнялась с использованием объектов в памяти. Для того, чтобы эта работа была воспроизводимой, нам нужна файловая запись всего этого. Итак, Pods.xcodeproj записывается на диск вместе с двумя другими очень важными файлами, Podfile.lock и Manifest.lock.

Местный подспец
CocoaPods против Карфагена
Версия CocoaPods

Источник здесь