Как обновить один блок, не касаясь других зависимостей

Я понимаю, что следующая команда обновит один модуль: pod update <podname>. Однако это также обновляет зависимости других модулей (модулей, которые не были включены в команду обновления), которые вы ранее установили. Есть ли способ обновить один блок и оставить все остальные зависимости отдельно?

Ответ 1

Убедитесь, что у вас установлена последняя версия CocoaPods. $ pod update POD был недавно представлен.

Подробнее об этом читайте в этой теме::

$ pod update

При запуске pod update SomePodName CocoaPods попытается найти обновленную версию модуля SomePodName, не принимая во внимание версию, указанную в Podfile.lock. Он обновит модуль до последней возможной версии (при условии, что он соответствует ограничениям версии в вашем Podfile).

Если вы запускаете обновление модуля без имени модуля, CocoaPods обновит каждый модуль, указанный в вашем Podfile, до последней возможной версии.

Ответ 2

Чтобы установить один модуль без обновления существующих → Добавить этот код в ваш подфайл и использовать:

pod install --no-repo-update

Чтобы удалить/обновить использование определенного элемента:

pod update POD_NAME

Испытано!

Ответ 3

Это 2015

Так как pod update SomePod затрагивает все в последних версиях cocoapods, я нашел обходное решение.

Следуйте следующим шагам:

  • Удалите SomePod из Podfile

  • Запустите pod install

Теперь pods удалит SomePod из нашего проекта и из файла Podfile.lock.

  1. Верните SomePod в Podfile

  2. Запустите pod install снова

На этот раз последняя версия нашего модуля будет установлена ​​и сохранена в Podfile.lock.

Ответ 4

просто говорю:

pod install - для установки новых модулей,

pod update - для обновления существующих модулей,

pod update podName - для обновления только определенных модулей, не касаясь других модулей,

pod update podName versionNum - для обновления/скачивания определенного модуля, не касаясь других модулей

Ответ 5

Просто небольшое уведомление.

pod update POD_NAME

будет работать, только если этот модуль уже установлен. В противном случае вам придется обновить все из них с помощью

pod update

Команда

Ответ 6

Я использую cocoapods version 1.0.1, и использование pod update name-of-pod отлично работает. Никакие другие модули не обновляются, а только конкретный, который вы вводите.

Ответ 7

Это немного странно, и вряд ли это будет с OP, но pod update <podname> не будет работать во всех случаях, если вы используете локальный модуль на вашем компьютере.

В этой ситуации единственное, что приведет к срабатыванию pod update, - это изменение файла podspec. Однако внесение изменений также позволит работать с pod install.

В этой ситуации вы можете просто изменить что-то второстепенное, например описание или резюме, по одной букве, а затем успешно выполнить команду установки или обновления.

Ответ 8

tl;dr use:

pod update podName

Почему? Читай ниже.

  • pod update НЕ будет уважать podfile.lock. Это переопределит это.
  • pod update будет уважать podfile.lock

Эта диаграмма помогает лучше понять различия:

enter image description here


Основная проблема связана с ~> ака оптимистическим оператором.

Использование точных версий в Podfile недостаточно

Некоторые могут подумать, что указание точных версий своих модулей в Podfile, например, pod 'A', '1.0.0', достаточно, чтобы гарантировать, что у каждого пользователя будет такая же версия, как и у других людей в команде.

Тогда они могут даже использовать pod update, даже просто добавляя новый модуль, думая, что никогда не рискнет обновить другие модули, потому что они зафиксированы в определенной версии в Podfile.

Но на самом деле этого недостаточно, чтобы гарантировать, что user1 и user2 в нашем вышеупомянутом сценарии всегда получат одинаковую версию всех своих модулей.

Типичным примером является случай, когда модуль A зависит от модуля A2, объявленного в A.podspec как dependency 'A2', '~> 3.0'. В таком случае использование pod 'A', '1.0.0' в вашем Podfile действительно заставит user1 и user2 всегда использовать версию 1.0.0 pod A, но:

  • У user1 может быть pod A2 в версии 3.4 (потому что это была A2 последняя версия в то время)
  • в то время как когда user2 запускает pod install при последующем присоединении к проекту, он может получить pod A2 в версии 3.5 (потому что сопровождающий A2, возможно, выпустил новую версию за это время). Поэтому единственный способ гарантировать, что каждый член команды работает с одинаковыми версиями всех модулей на каждом компьютере, - это использовать Podfile.lock и правильно использовать pod install против pod update.

Вышеприведенный отрывок был получен из pod install или pod update

Я также настоятельно рекомендую посмотреть , что делает podfile.lock