Использование зависимости CocoaPod при разработке CocoaPod

Question

Я создаю CocoaPod, скажем MyPod, что зависит от другого Cocoapod, скажем RxSwift.

Так что у меня это в MyPod.podspec:

s.dependency "RxSwift", "~> 3.0.1" 

Однако при разработке MyPod, как я могу на самом деле использовать зависимость?

import RxSwift 
// ^
// No such module 'RxSwift' 

public class MyClass { //... 

Есть ли какой-то шаг, который мне не хватает, или какое-то общее соглашение? Похоже, что некоторые другие проекты, такие как Moya, используют Carthage для создания зависимостей при разработке. Должен ли я делать это, или, может быть, добавить Podfile?

Я знаю, что это не должно быть проблемой для приложения примера, расположенного внутри репо, которое будет иметь свой собственный Podfile. Тем не менее, я бы хотел, чтобы тесты находились на верхнем уровне, за пределами App-приложения, и чтобы иметь возможность фактически создавать фреймворк во время работы над ним, опять же, за пределами приложения-примера.

Answer 1

В итоге я использовал Карфаген для создания зависимостей структуры. Думаю, я мог бы использовать CocoaPods, чтобы это сделать. Тем не менее, это потребовало бы, чтобы я начал использовать рабочее пространство, и я не хотел этого делать, чтобы изменения были минимальными, насколько это возможно.

Кроме того, с Карфагеном, он не требует, чтобы добавить новый Podfile/Podfile.lock, так как Карфаген будет использовать существующий Cartfile/Cartfile.resolved, что уже есть. Это потому, что Карфаген использует Cartfile.resolved при использовании фреймворка в другом проекте и при построении рамки самостоятельно. Принимая во внимание, с CocoaPods, *.podspec используется при использовании рамки в другом проекте ноPodfile.lock (, если вы добавили Podfile) необходимо установить зависимые стручки в самой структуре.

Answer 2

Я не могу говорить, использовать или не использовать CocoaPods или Carthage. У обоих есть свои сильные стороны и слабые стороны. Кроме того, решение должно быть принято с учетом многих факторов, некоторые из которых вы, возможно, не сможете контролировать (например, клиент, который настаивает на использовании CocoaPods!) Поэтому я пропущу эту часть.

Однако, на ваш вопрос, действительно, стручок, который вы разрабатываете, может зависеть от другого контейнера. У вас уже есть правильная линия s.dependency. Это необходимо.

Однако я подозреваю, что причина, по которой вы не могли ссылаться на зависимый блок, может быть потому, что у вас не было подфайла в вашем проекте «Тестер/пример» и/или вы не сделали pod install после добавления зависимость в вашем Podspec.

Причина, по которой я подозреваю, заключается в том, что, поскольку Podspec фактически не обрабатывается Xcode, вы фактически не загружаете (или не компилируете) зависимость.

Вместо этого, когда вы выполняете установку pod (через командную строку, конечно), CocoaPods создаст проект Pods с вашим модулем разработки, на которых вы зависите (в Podspec), а также с любыми другими модулями вашего подфайла.

Чтобы проверить эту теорию, я:

• Создано новый стручок (используя собственный CocoaPod в «стручок Lib создать» (https://guides.cocoapods.org/making/using-pod-lib-create.html)
• Открыл рабочее пространство, которое CocoaPod, созданный для меня и редактировал Podspec к. добавить зависимость s.dependency 'RxSwift', '~> 3.0.1'.
• Добавлен еще один стручок в моем примере приложения Podfile (чтобы продемонстрировать разницу между Podfile зависимостей и Podspec зависимостей.)
• Выполненный pod install в folde на примере приложения р.
• Редактировал класс моего Pod, чтобы сделать что-то полезное и добавить строку import RxSwift.
• Добавлен ярлык к моему примеру (конечно, «Hello World»).
• Б PureLayout сделать все ограничение Автокомпоновки для метки (и продемонстрировать, как пример проект имеет доступ к обеим стручкам -. Стручку развития, а также ссылочному стручок PureLayout)

Вы можете проверить из демо я создал в моем общедоступном GitHub: https://github.com/ericwastaken/CocoaPod-Dependency-Demo

Честно говоря, я создал несколько стручков с помощью pod lib create и действительно создать хорошую структуру, которая всегда работал для меня. По этой причине я бы рекомендовал всегда использовать его для создания скелета вашего контейнера.

Xcode 8 комментарий: pod lib create все еще, кажется, создает проект Swift 1.x. Итак, сразу после использования этого инструмента, когда вы открываете Xcode, вам будет предложено «преобразовать» в более новую версию Swift. Я бы допустил, чтобы это преобразование произошло сразу и там (в первый раз), чтобы вы могли быть в синтаксисе Swift 2.x или 3.x (вы выбираете).