Comments 15
Всем, кто будет переносить свои зависимости с генерацией
Package.swift, дам два важных совета:
Редактируйте
Package.swiftпрямо в Xcode.
ничего не понял. Так вы редактируете Package.swift или генерируете его?
x86_64 — для симулятора.
x86_64 это симулятор под интел процессор, на силиконе уже идет под натив тоже arm64.
Всё, что нужно — ввести логин и пароль от приватного репозитория при добавлении его в проект. Это придется сделать всем, кто впервые затягивает обновленный проект.
если прописать путь до репозитория через git@git, а не https, то доступ будет без ввода пароля по ssh ключу.
До сих пор обхожу SPM стороной, на мой взгляд очень корявая вещь в плане скорости работы. Основной проект перевел на Carthage и оставил 10% на Cocoapods. Сборка проекта на СИ 1 минута 20 секунд для тестов. Когда открываешь проект то моментально можно работать, индексация кода происходит почти мгновенно.
Есть проект на SPM такого же размера, вот адище где, на СИ только spm resolve работает 3 минуты, что там так долго можно резолвить я до сих пор не понимаю, но собирает из кеша, что не плохо. Индексация проекта занимает колоссальное время потому что индексирует по-видимому все все сорцы засивимостей, я когда открываю проект просто ухожу на 10 минут пить кофе. AppCode и Xcode с SPM зависимостями съедает кучу оперативки в отличии от Carthage + SPM.
Как только понадобится SPM зависимость буду интегрировать через Scipio https://github.com/giginet/Scipio
Спасибо за статью! чем больше читаю про SPM тем больше понимаю ну его к черту))
Carthage к сожалению пока не было возможность попробовать, надеюсь этот проект не постигнет участь cocoapods, раз он так хорош в работе) SPM еще местами кривоват, но вот по производительности проблем не заметил, у нас в проекте 50+ зависимостей (если считать зависимости зависимостей), собирается чуть быстрее, чем было с cocoapods, около 5 минут
Class _TtC9Alamofire11DataRequest is implemented in both /private/var/containers/Bundle/Application/7AC9F854-BBAC-437A-B556-4DB94E6017DA/Foo.app/Frameworks/Alamofire.framework/Alamofire (0x10193aaf0) and /private/var/containers/Bundle/Application/7AC9F854-BBAC-437A-B556-4DB94E6017DA/Foo.app/Foo.debug.dylib (0x1075719b8). One of the two will be used. Which one is undefined.
У вас Alamofire положен в виде динамической библиотеки в бандл приложения, скорее всего Cocoapods это сделал если не указано явно в Podfile static linkage. А SPM с недавних пор стал ликовать статично (в бинарник). Первое что приходит в голову это подправить возможно в Podfile чтобы после pod install этой либе прописывалась weak_framework или что-то подобное, но скорее всего да придется лезть еще глубже.
У меня тоже была подобная проблема, когда часть зависимостей ушли в Carthage, но часть зависимостей осталась в Cocoapods и им нужны эти Carthage либы. Пришлось форкать и править podspec чтобы этих зависимостей не было в podspec, а на pod install для этих зависимостей прописывать зависимости на Carthage. Но это того стоило, у нас как только RxSwift и его обвязка ушла в Carthage сразу стало на минуту быстрее собираться минимум. А когда ушли все гугловые либы так еще много минут ушло и из компиляции и индексации так как гугловый Firebase тянет за собой тонну сишных либ, один только grpc либа собирается пару минут.
x86_64 — для симулятора.
вспомнил, у нас давно тоже была библиотека только под интел, а с проектом уже работали на новых силиконах. Так вот, если в проекте есть либа под интел (x86_64), то и весь проект насколько помню будет собираться под интел и запускаться приложение на симуляторе будет через трансляцию Rosseta. Посмотрите в Xcode Build логах под какую архитектуру он собирает проект под симулятор при отсутствии либы под натив ?
Например, если одна библиотека через SPM тащит
Alamofire, а другая через CocoaPods — тоже, то при запуске приложения получите кучу ошибок вида:
Class _TtC9Alamofire11DataRequest is implemented in both /private/var/containers/Bundle/Application/7AC9F854-BBAC-437A-B556-4DB94E6017DA/Foo.app/Frameworks/Alamofire.framework/Alamofire (0x10193aaf0) and /private/var/containers/Bundle/Application/7AC9F854-BBAC-437A-B556-4DB94E6017DA/Foo.app/Foo.debug.dylib (0x1075719b8). One of the two will be used. Which one is undefined.
1)это не ошибка, а Warning. Билд может вести себя непредсказуемо, но вы его вполне можете собрать (если конечно там не разные major версии, несовместимые между собой)
2)допустим у вас все-таки ошибка, но SPM-то тут причем? В проекте, содержащем только cocoapods будет почти то же самое, только он сначала выкачает одну версию библиотеки, потом другую.
но SPM-то тут причем?
по идее есть причем. SPM положил код в основной бинарник, а Cocoapods в виде динамики. Когда рантайм запустился то одна и та же функция есть в 2х местах и не известно что из них будет использовано. То есть нужно перестраивать или spm или cocoapods чтобы убрать warning. Но вы правы это всего лишь варнинг, и в нем нет ничего страшного если знать что он значит. Но я когда такое видел в консоли то не могу такое терпеть ибо не по феншую, я просто на cocoapods post install правил проект чтобы их убрать.
в моем случае 2 сторонних пода ссылались на одну и ту же библиотеку разных версий + походу cocoapods проверяет совместимость версий только на "верхнем" уровне. Вот и получалось - один под тянет себе одну версию, второй тут же ее перебивает. Исправлял добавлением еще одной зависимости на эту же библиотеку - в основной проект, причем на конкретную версию.
в моем случае 2 сторонних пода ссылались на одну и ту же библиотеку разных версий + походу cocoapods проверяет совместимость версий только на "верхнем" уровне.
Нужно смотреть как прописаны версии зависимостей, насколько строго или свободно (https://guides.cocoapods.org/syntax/podfile.html#pod), поидее в Podfile.lock прописаны финальные версии на что зарезолвил cocoapods. Согласен, беда когда коллизия версий происходит.
да, у меня в проекте как раз были разные major версии
Еще я не понял из статьи, что делать с зависимостями, которые выгодно держать именно в виде cocoapods? Это сторонние библиотеки, которые регулярно обновляются, доступны только через cocoapods (и импортирование исходниками вручную), и альтернативы им нет.
Переносить их в SPM пришлось бы при каждом обновлении вручную, насчет смешанных источников не знаю (они скрыты). Вы бы оставляли их как есть?
Еще вспомнил, чем нам SPM колеса вставлял. Мы в одной тяжелой репе сделали SPM зависимость и ее подключали в проекта в другой репе. Так как репа либы весила 1 Гб, то SPM не только первый раз ее выкачивал полностью, а вообще всегда ее выкачивал, то есть почти на любой чих он качал 1 Гб что примерно занимало ожидание в 10 минут при открытии проекта. Cocoapods один раз скачивал и потом просто докачивал репу и ресетился на нужный коммит/версию. Когда мы с помощью специальной тулы убрали из репы тяжелые файлы то Cocoapods как полагается скачивал репу мгновенно, но SPM особенный и клонит репу с --mirror флагом вместо shallow (https://github.com/swiftlang/swift-package-manager/issues/6062), что запрашивает с сервера гита из кеша, то есть в нашем случае он снова скачивала удаленные бинарники на 1 Гб. Пришлось писать git core team чтобы они дропнули всё из кеша гита нашего репозитория.
Игра в SPM