CocoaPods как установить только одну новую библиотеку

Ответ 1

pod install --no-repo-update

Это устанавливает новые элементы без обновления существующих репозиториев (версий или нет).

Это также быстрее, если у вас много репо и требуется быстрая установка нового элемента.

Ответ 2

Если вы не хотите обновлять определенные библиотеки, вы должны заблокировать их в версиях, которые вы хотите сохранить

pod 'AFNetworking', '1.2.0'
pod 'JSAnimatedImagesView', '~> 1.0.0'

Сохраняйте AFNetworking на V1.2.0, но получите последний JSAnimatedImagesView

Это делает перенос podfile в другие места (и разработчики) и избавляет вас от забывания, чтобы вернуть ваш файл подкачки, пока вы не собираетесь обновлять модули

Ответ 3

Вы можете попробовать использовать команду update https://guides.cocoapods.org/terminal/commands.html#pod_update

pod update [POD_NAMES ...]

Обновляет объекты, идентифицированные указанным POD_NAMES. Если POD_NAMES не заданы, он обновляет все Pod, игнорируя содержимое Podfile.lock.

Ответ 4

При запуске с проектом, вероятно, вы захотите использовать последнюю версию Pod. Если это так, просто опустите требования к версии.

pod 'SSZipArchive'

Позже в проекте вы можете захотеть заморозить определенную версию Pod, и в этом случае вы можете указать этот номер версии.

pod 'Objection', '0.9'

Дополнительная информация http://guides.cocoapods.org/syntax/podfile.html#pod

Ответ 5

Добавить новый pod repo в ваш podfile и использовать следующую команду

pod install

Источник формы примера pod install vs. pod update

Пример сценария

Вот пример сценария, иллюстрирующий различные варианты использования, которые могут возникнуть в течение жизни проекта.

Этап 1: User1 создает проект

user1 создает проект и хочет использовать элементы A, B, C. Они создают Podfile с этими контейнерами и запускают установку pod.

Это установит элементы A, B, C, которые мы скажем, все в версии 1.0.0.

Подфайл .lock будет отслеживать это и отметить, что A, B и C установлены как версия 1.0.0.

Кстати, поскольку в первый раз они запускают установку pod и проект Pods.xcodeproj еще не существует, команда также создаст Pods.xcodeproj и .xcworkspace, но это побочный эффект команды, а не его основной роли.

Этап 2: User1 добавляет новый pod

Позже пользователь1 хочет добавить pod D в свой подфайл.

Затем они должны запустить pod install после этого, так что, даже если тестеран pod B выпустил версию 1.1.0 своего модуля с момента первого выполнения установки pod, проект будет продолжать использовать версию 1.0.0 - потому что только user1 хочет добавить pod D, не рискуя неожиданным обновлением до B.

Что, когда некоторые люди ошибаются, потому что они используют обновление pod здесь, возможно, думая об этом как "Я хочу обновить свой проект новыми модулями"? - вместо использования pod install - для установки новых модулей в проекте.

Этап 3: User2 присоединяется к проекту

Тогда пользователь2, который никогда не работал над проектом раньше, присоединяется к команде. Они клонируют репозиторий, затем используют установку pod.

Содержимое Podfile.lock(которое должно быть привязано к репо git) гарантирует, что они получат одни и те же файлы, с теми же версиями, что и пользователь1.

Даже если теперь доступна версия 1.2.0 pod C, пользователь2 получит pod C в версии 1.0.0. Потому что это то, что зарегистрировано в Podfile.lock. pod C заблокирован до версии 1.0.0 под Podfile.lock(отсюда и название этого файла).

Этап 4: Проверка новых версий модуля

Позже пользователь1 хочет проверить, доступны ли какие-либо обновления для контейнеров. Они запускают pod устаревшие, которые скажут им, что pod B имеет новую версию 1.1.0, а pod C выпустила новую версию 1.2.0.

user1 решает, что они хотят обновить pod B, но не pod C; поэтому они будут запускать обновление pod p, которое обновит B от версии 1.0.0 до версии 1.1.0 (и соответственно обновит Podfile.lock), но сохранит pod C в версии 1.0.0 (и не обновит его до версии 1.2. 0).