CocоaPods — мощное средство в руках Objective-C разработчика

    CocoaPods — это мощное и одновременно изящное средство управления зависимостями Cocoa-библиотек, которые разработчики используют в своих iOS и MacOS X проектах. Как обычно для Cocoa-статей мы сфокусируемся именно на iOS разработке.




    iOS-разработчики любит использовать наработки других разработчиков (3rd party разработчиков). И как правило, библиотеки поставляются с исходным кодом. И обычно мы добавляем исходный код библиотек в наш проект, однажды взяв его из репозитория разработчиков. У такого подхода есть несколько недостатков:

    • Иногда бывает сложно уследить за версиями библиотек и их связями между собой
    • Нет одного общего места, где можно просмотреть список всех доступных библиотек. Безусловно, github — одно из крупных пристанищ opensource-проектов, но не единственное
    • Необходимо всегда помнить про то, что исходных код таких библиотек нужно обновлять. (отчасти проблему решили бы средства наподобие git submodules)
    • Когда вы скачиваете исходники и добавляете в свой проект часто возникает соблазн изменить код библиотеки локально, что в будущем создать головную боль при обновлении библиотеки.


    Средства управлением зависимостями CocoaPods поможет решить многие упомянутые проблемы. CocoaPods разберется с зависимостями между библиотеками, которые вы используете, скачает их, создаст и будет поддерживать структуру проекта в надлежащем виде.

    С CocoaPods создать проект, использующий сторонние наработки, намного проще. И так, приступим.

    Начинаем


    Согласно официальному сайту, CocoaPods — это лучшее средство по управлению зависимостями библиотек в Objective-C проектах.

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

    Например, нам необходимо сделать приложение, которые будет общаться с RESTfull API какого-нибудь сервиса, используя JSON.

    Наиболее популярная библиотека для работы с HTTP-запросами — это AFNetworking (с тех пор, как ASIHTTPRequest перестала поддерживаться).

    Для начала нам необходимо установить CocoaPods. CocoaPods — это Ruby проект, и к нашему счастью интерпретатор Ruby идет в стандартную комплектацию MacOS. Ruby — это единственная зависимость CocoaPods, и сперва нам необходимо обновить список пакетов, в терминале выполнив команду:


    Возможно, для корректной работы нам сперва необходимо будет обновить или установить Command Line Tools for XCode. Сделать это можно, зайдя по XCode > Preferences > Downloads > Components.

    После того, как список пакетов обновлен, мы можем установить CocoaPods:

    sudo gem install cocoapods &&
    pod setup


    CocoaPods установлен.

    Hello World


    Создаем новый почти пустой проект File > New > Project… > Single View Applciation, для примера:



    Добавляем первую зависимость


    Ну вот и он — момент истины. Добавляем нашу первую зависимость в проект.

    В терминале переходим в папку проекта и выполняем следующее:
    1) Создает Pod-файл

    2) Добавляем библиотеку


    Как можно увидеть, формат файла завиcимостей довольно простой. Мы добавили строку с AFNetworking и указали, что нас интересует последняя, 0.10.0 версия.
    Тут подробно рассказано о формате Pod-файла.

    3) Генерируем первоначальное окружение, загружаем необходимые файлы как самого CocoaPods, так и исходники библиотек. И главное — будет всегда поддерживать их в актуальном состоянии:
    pod install


    После выполнения этих несложных процедур мы получаем новую заготовку проекта. Теперь работать с ним нужно через сгенерированный xcworkspace. То есть забудьте о файле проекта как о самостоятельной сущности, только workspace!

    open CocoaPodsExample.xcworkspace

    Вот так будет выглядеть структура проекта


    Теперь можно смело подключать AFNetworking.h и использовать эту библиотеку будто вы сами только что скачали ее исходники и разместили их в своем проекте.


    Собственно, это, пожалуй, основной путь работы с CocoaPods. Основной, минимальный и простой.

    Файл с зависимостями можно будет дополнить, разбавив одинокий AFNetworking:

    pod 'SSToolkit'
    pod 'AFNetworking', '>= 0.5.1'
    pod 'CocoaLumberjack'

    Суть не меняется, простота работы не пропадает.

    Вот список наиболее популярных библиотек, доступных через CocoaPods:

    • AFNetworking
    • ASIHTTPRequest
    • BlocksKit
    • ConciseKit
    • CorePlot
    • EGOTableViewPullRefresh
    • Facebook-iOS-SDK
    • JSONKit
    • MBProgressHUD
    • Nimbus
    • QuickDialog
    • Reachability
    • SFHFKeychainUtils
    • ShareKit


    CocoaPods однозначно можно отнести к must have средствам в арсенале Cocoa-разработчика.
    image
    Luxoft
    149,00
    think. create. accelerate.
    Поделиться публикацией

    Комментарии 52

      +2
      Добавьте уж и создание своих Podspec'ов (например для использования чужого репа), разделение подов по таргетам, ну само создание собственного подспека. А то так статья кажется какой-то неполной.
      За обзор спасибо, этот инструмент нужно внедрять в массы.

      ЗЫ. почему AFNetworking а не RestKit?
        0
        Именно! Это пока первая статья для внедрения в массы. Потом и создание своих Podspec'ов. Ну и «AFNetworking vs RestKit» можно будет обсудить.
          +1
          Я думаю что стоило рассказать именно здесь о создании спеков для чужих либ, т.к. первый контраргумент который я услышал о CocoaPods был как раз о том, что мол «а как быть если нужная фича лежит в другой ветке, или другом коммите относительно добавленного тэга».
          И это действительно бывает проблематичным, когда нашел какую-то хорошую либу, а она уже год как не поддерживается и естественно никакой поддержки CP не имеет, вот здесь и приходят на помощь свои podspec'и, размещенные, к примеру, в гистах на гитхабе.
          +1
          А почему AFNetworking vs RestKit, а не это? github.com/EmbeddedSources/iAsync/tree/master/lib/JFFNetwork
            0
            Субъективно считаю RestKit более популярным чем остальные вещи.
            0
            >>> этот инструмент нужно внедрять в массы.
            Только не забывайте предупреждать массы о том что это по своей сути костыль copypaste вселенских масштабов.

            А на мой взгляд, внедрять в массы нужно умение правильно писать свои библиотеки и frameworks. А то iOS developers отстают от своих коллег в этом плане лет эдак на 50.
              0
              В этом я с вами полностью согласен, только не то чтобы писать, а хотя бы распространять.
                0
                в чем тут copy-paste? В том что дерево исходников зависимостей лежит рядом с проектом?
                  0
                  тогда и git тоже copy paste
              • НЛО прилетело и опубликовало эту надпись здесь
                  0
                  Модераторы там молодцы, один из подспеков смержили, а потом молча поправили там опечатку в имени классов и все, приятно.
                  0
                  Первый раз слышу о такой полезной штуке, нужно попробовать. Огромное спасибо за информацию.
                    0
                    Полезная статья. Как раз даны основы, в следующих статьях можно рассказать и о кастомных podspec-ах и прочие прелести. Впервые узнал про CocoaPods как раз в комментариях к одной из статей, потом раз за разом встечал упоминания на хабре, вот наконец-то отдельный рассказ.
                      0
                      Что-то не получается (10.8):

                      [17:09 styx@iHome:/Users/styx] sudo gem install cocoapods
                      ...
                      16 gems installed
                      ...
                      Installing ri documentation for activesupport-3.2.8...
                      
                      unrecognized option `--encoding'
                      
                      For help on options, try 'rdoc --help'
                      
                      ERROR:  While generating documentation for activesupport-3.2.8
                      ... MESSAGE:   exit
                      ... RDOC args: --ri --op /Library/Ruby/Gems/1.8/doc/activesupport-3.2.8/ri --encoding UTF-8 lib --title activesupport-3.2.8 Documentation --quiet
                      
                        0
                        Попробуйте так
                        [sudo] gem install cocoapods --no-ri --no-rdoc
                        

                        Не думаю что эти доки вам пригодятся ;-)
                        +2
                        Итак, ложка дегтя, о которой автор умолчал:

                        >> И обычно мы добавляем исходный код библиотек в наш проект, однажды взяв его из репозитория разработчиков.
                        добавлять нужно не код, а собранные библиотеки и framework

                        >> Иногда бывает сложно уследить за версиями библиотек и их связями между собой
                        Когда они ПРАВИЛЬНО собраны в universal library или framework — проблем со связями никаких

                        >> Нет одного общего места, где можно просмотреть список всех доступных библиотек.
                        а CocoaPods разве всезнающий?

                        >>Когда вы скачиваете исходники и добавляете в свой проект часто возникает соблазн изменить код библиотеки локально, что в будущем создать головную боль при обновлении библиотеки.
                        а сделать fork и послать pull request разработчикам вам не под силу? Или есть неизвестные проблемы с «git remote add» / «git merge»?

                        Главное — не сказано что из себя представляют эти CocoaPods.
                        Это script на ruby, который вытаскивает из github исходники и добавляет их в проект по методу «drag and drop», популярному среди так называемых iOS developer. Получается одна толстая библиотека, в которую тупо компилируются все зависимости.

                        Из минусов варианта со static library/framework то, что разработчики библиотек медленно приходят к этому подходу. приходится некоторое время maintain-ить свой fork.

                        Уже есть некоторое количество исправленных нами ( github.com/EmbeddedSources ) библиотек
                        * CLCascade
                        * TouchXml
                        * EGOTableViewPullRefresh
                        * CocoaLumberjack
                        * MagicalRecord
                        * RBFilePreviewer
                        Большинство из оных pull request-ов уже приняты разработчиками библиотек.

                        >> CocoaPods однозначно можно отнести к must have средствам в арсенале Cocoa-разработчика.
                        я лично в этом сомневаюсь.
                        А вы?
                          0
                          Мне кажется, но как описываете Вы, делают далеко не все. Некоторые еще и хардкодят при этом.
                            –1
                            >> Некоторые еще и хардкодят при этом.
                            Вот им и трудно хардкодить. Потому и изобрели CocoaPods.
                            С моей точки зрения данный инструмент — большой автоматизированный серебряный костыль. Хотя кому-то, возможно, так удобней.

                            >> как описываете Вы, делают далеко не все
                            Я не один такой. автор ghUnit тоже так делает. Может, прочитав это обсуждение кто-либо еще пополнит ряды таких людей.

                            P.S. Не вполне понял вашу орфографию. Уж не взыщите
                            0
                            Ну не знаю, мне удобнее когда есть пачка сырцов, так или иначе бывает нужно посмотреть как оно работает, или посмотреть бэктрэйс, а вот собранная либа мне этого не позволит, просто вылетит непонятно где и все.
                            Да и главный плюс CP на мой взгляд, это то что мне не нужно прописывать для каждой либы Other Linker Flags, добавлять Frameworks и т.п. вещи, которые порой занимают немало времени и изядно раздражают.
                              0
                              >>> так или иначе бывает нужно посмотреть как оно работает, или посмотреть бэктрэйс, а вот собранная либа мне этого не позволит

                              Ну так собирайте на здоровье! Или вы target dependencies не смогли осилить?
                              image

                              Если кто заинтересовался, то код тут

                              >>> мне не нужно прописывать для каждой либы Other Linker Flags, добавлять Frameworks
                              да. Добавить собранный framework с помощью «drag and drop» особенно тяжко…
                              Вам не послышалось: свой framework нужно тащить к Foundation и прочим ( см. картинку выше ).

                              >>> Да и главный плюс CP на мой взгляд, это то что мне не нужно прописывать для каждой либы Other Linker Flags.
                              Если есть исходники — делаем dependence ( см. картинку ).
                              Иначе — у вас есть universal binary + набор headers. Делаем руками из этого всего framework. Дальше — ваш излюбленный drag and drop.

                              В общем, если это правильно приготовить, то можно обойтись и без hard core типа Linker Flags, и без костылей подобных CocoaPods.

                              P.S. а немало времени порой занимает наведение порядка в сторонней библиотеке, заточенной под copy paste. А раздражает то, что многие, называющие себя «iOS developer», так и используют copypaste, считая это прекрасным способом повторного использования кода.

                              Может, для ruby подобный подход и оправдан. Но Objective C++ ведь не интерпретируемый (и слава богу).

                              P.S. Если у вас еще остались аргументы в пользу CocoaPods — готов выслушать.
                                0
                                Зачем мне что-то собирать и drag'n'drop-ать если я могу все это сделать просто добавив всего лишь одну строчку в файл и запустить команду в терминале? Я привык пользоваться bundler'ом из RoR и подобный подход считаю очень удобным.
                                Делать форки всех интересующих либ, добавлять в них таргет для фрэймворка… Зачем мне все это если я хочу сэкономить время?
                                Ни один из ваших аргументов я не считаю существенным минусом.
                                CP экономит мое время и потому я им пользуюсь.

                                И, кстати, я в курсе как собирать bundle'ы и я не люблю drag'n'drop.
                                  0
                                  Видать, все дело в том что я пришел в iOS development из сурового бородатого C++
                                  И уже привычен к ручным ( ну, или с помощью CMake ) сборкам зависимостей.

                                  >>> Зачем мне все это если я хочу сэкономить время?
                                  1. Framework way идеологически более верен для данной платформы. Framework programming guide
                                  2. Для следующих проектов framework добавляется очень быстро и безболезненно. Так же как для Mac OS X, поскольку используется единый xCode.
                                  3. Помочь сообществу, правильно оформив хорошие библиотеки. Чтобы даже команду в терминале запускать не нужно было. Скачал собранный framework, перетащил — и пользуйся на здоровье.
                                  В качестве примера — тот же gh-unit

                                  И да. В случае Ruby обычно executable == source code. В случае C++/Objective-C сей подход не вполне оправдан.
                                    0
                                    Я всегда рад помочь сообществу, но не всегда есть на это время, и не всегда принимаются PR, проект может быть просто запущен…
                                    В итоге я делаю вывод что это палка о двух концах, пока мейнтейнеры библиотек не начнут делать хороший саппорт нам прийдется юзать всякие разные костыли и тратить время.
                                      0
                                      > Чтобы даже команду в терминале запускать не нужно было. Скачал собранный framework, перетащил — и пользуйся на здоровье.

                                      Спорный аргумент. По мне, так поправить файл и запустить `pod install` несколько проще, чем выкачивать и подключать вручную. Особенно когда либы с зависимостями.
                                        0
                                        Вот только «либу с зависимостями» и framework (хорошо, несколько framework, ежели у нужного вам есть зависимости) путать не стоит.

                                        С библиотеками — да. Возня есть. Но если уж из нее добрые люди скрутили framework, то подключение сводится к «скачал->drag&drop->можно пользоваться».

                                        P.S. Товарищ дело говорит.
                                        >> На вид все довольно просто, но мне кажется для управления зависимостями в проекте предоставляется слишком большая абстракция, делегирование управления и возможность загнать себя в рамки инструмента
                                          0
                                          Хм, а чем фреймвок с зависимостями принципиально отличается от либы с зависимостями?

                                          И в том и в другом случае необходимо самостоятельно эти зависимосты трэкать, выкачивать и добавлять в проект. Повторить при необходимости обновиться до свежей версии.
                                          Это может еще осложниться тем, что dependent библиотека может поддерживать не все версии своих dependencies.

                                          Инструменты подобные cocoapods как раз и существуют, чтобы этот процесс упростить и автоматизировать.

                                          К аналогичный подходу к dependency management'у рано или поздно приходят многие платформы.
                                          Прототипом данного проекта, насколько я понимаю, является рубишный bundler; похожие по функционалу инструменты уже существуют для erlang (rebar), node.js (npm), с некоторой натяжкой сюда же можно добавить и maven для java.
                                            0
                                            Framewok == библиотека + headers + resources.
                                            Отличие — интеграция с xCode. Имея framework не нужно ничего прописывать в header search path и linker flags. Нужную зависимость будет добавить так же легко как Foundation или UIKit, предоставляемые Apple.

                                            >> И в том и в другом случае необходимо самостоятельно эти зависимосты трэкать, выкачивать и добавлять в проект.
                                            Не совсем так. Скачать, собрать из них framework и его добавить. Согласитесь, обновление third party библиотек — не столь частая штука, чтобы пересобирать их каждый раз на основе nightly builds.

                                            >> К аналогичный подходу к dependency management'у рано или поздно приходят многие платформы
                                            Ага. Особенно те, у которых source code == executable. То есть, интерпретируемые языки (в основном, они и попали в ваш список).

                                            Ну неправильно это — использовать copy-paste для повторного использования кода в компилируемых языках, таких как C++ и ObjectiveC. В своем любимом .NET или Java вы ведь исходники библиотек не включаете в основной проект? Конечно, нет, ведь вы создаете package (*.dll или *.jar соответственно). Аналогичный подход стоит применять к ObjectiveC, взяв framework в качестве подобного package.

                                            >> Инструменты подобные cocoapods как раз и существуют, чтобы этот процесс упростить и автоматизировать.
                                            Вот если бы CocoaPods собирал мне нужные frameworks, а не тупо вставлял исходники в мой проект (хорошо, в отдельный static library project) — цены бы ему не было. А так это большой и удобный костыль, поощряющий неряшливый стиль работы с зависимостями и построения собственных библиотек.

                                            >> с некоторой натяжкой сюда же можно добавить и maven для java
                                            А если еще больше натянуть, то можно добавить и make для ObjectiveC чего угодно
                                              +2
                                              Так, еще раз. Я не спрашивал, что такое фреймворк. Я спрашивал в чем принципиальное отличие при мэнеджменте зависимостей.

                                              Да, фреймворк, для подключения в проект лучше, чем копирование исходников. Но фреймворк — это не инструмент управления зависимостями. На трэкинг зависимостей сборка фреймворка вообще никак не влияет. Зависимости приходится находить (в простейшем случае они будут в доке/ридми упомянуты) и добавлять по-отдельности.

                                              Вы упорно отказываетесь понимать, что я говорю в первую очередь про dependency-management. А с инструментами подобными cocoapods это делать удобнее.

                                              > Ага. Особенно те, у которых source code == executable. То есть, интерпретируемые языки (в основном, они и попали в ваш список).

                                              Я только что понял, что бы абсолютно не в курсе как работают bundler, npm и иже с ним.

                                              > А так это большой и удобный костыль, поощряющий неряшливый стиль работы с зависимостями и построения собственных библиотек.

                                              Не убедили.

                                              > А если еще больше натянуть, то можно добавить и make для ObjectiveC чего угодно

                                              Вот эту иронию я вообще не понял. Если говорить в контексте управления зависимостями maven работает крайне похожим образом.
                                              Но, в целом, можете дальше продолжать ерничать.
                                                0
                                                >>> Я только что понял, что бы абсолютно не в курсе как работают bundler, npm и иже с ним.
                                                Вы правы. Мне должно быть стыдно?

                                                >>> Зависимости приходится находить (в простейшем случае они будут в доке/ридми упомянуты) и добавлять по-отдельности.
                                                Нормальный maintainer должен бы выложить у себя framework своей библиотеки + набор framework для ее зависимостей. В случае коллизий выбирать или собирать нужный вариант прийдется вручную, но и CocoaPods, вроде как не особо спасает в таких случаях.

                                                Пока таких maintainer не встречал. Обычно код зависимостей также тупо скопирован в репозиторий библиотеки. В лучшем случае автор осилил git submodule.

                                                >>> Да, фреймворк, для подключения в проект лучше, чем копирование исходников.
                                                >>> Не убедили
                                                1. То есть, вы считаете копирование исходников нормальной практикой в случае ObjectiveC?
                                                2. Перечитайте еще раз мою аналогию с Java/.NET package.
                                                ну, не убедил, так не убедил. что поделаешь…

                                                >>> Вы упорно отказываетесь понимать, что я говорю в первую очередь про dependency-management. А с инструментами подобными cocoapods это делать удобнее.
                                                Вы упорно отказываетесь понимать, что я не против dependency management. Я категорически против copy-paste исходников. Для меня это критичней, чем удобство CocoaPods.

                                                Скорее всего, у меня и не получится убедить вас. Вы сделали выбор осознано.
                                                А многие тупо копируют исходники в проект потому что так было написано в tutorial, по которым они осваивали язык. И как раз эта особенность iOS community меня удручает.
                                                  0
                                                  Так это ручное копирование исходников в проект — это как раз следствие отстутствия инструмента а-ля CocoaPods в яблочном инструментарии из коробки.
                                                0
                                                да нет, maven тут как раз к месту, очень похожий workflow: прописали зависимости в файле, выполнили коносльную команду, вуаля, зависимости материализованы. Make, если что, зависимостями не управляет.

                                                Еще раз, что плохого в том, что Вы называете «copy-paste»? Под iOS все равно возможна только статическая линковка с зависимостями (кроме системных). Да даже под OS X, где возможна линковка динамическая, любое приложение — это self-contained bundle, со всеми зависимостями, и пользователю глубого фиолетово, будет там Framework или один толстый статически слинкованный исполняемый файл
                                                  0
                                                  >>> Даже под Windows/Unix можно все статически влинковать со всеми зависимостями, и и пользователю глубого фиолетово.

                                                  Но вы почему-то так не делаете?
                                                  В своих java проектах вы ведь используете *.jar, а не перетаскиваете *.java файлы в каждый новый проект? Вот и для ObjectiveC должен работать тот же принцип. К сожалению, не тут-то было.
                                                    0
                                                    Я не «не делаю так», мне просто без разницы, если конечный продукт нормально деплоится на целевую систему: 20 там джарок, или одна толстая. Аналогично и с iOS.
                                                    –1
                                                    >>> Make, если что, зависимостями не управляет.
                                                    да что вы говорите?

                                                    Он как раз зависимостями и управляет. Только не проека, а команд ( компиляции\линковки\установки итд. ). Да, низкоуровнево и не вполне удобно, но управляет ведь!
                                                      0
                                                      окей, под управлением зависимостями я понимаю «получение зависимостей по названию и номеру версии, подготовка к сборке проекта с зависимостями».

                                                      Вот первого пункта как раз в make нету, а в maven есть
                                            0
                                            я бы не сказал что Frameworks — более верный подход для iOS. Стоковым Xcode'ом даже static framework не собрать без костылей, если что.
                                              0
                                              Костыли не нужны. Нужен набор script-ов.

                                              Есть прекрасный target template ( хотя его можно было бы слегка упростить )
                                              github.com/kstenerud/iOS-Universal-Framework

                                                0
                                                ну это тоже стороннее решение, его нужно ставить и следить чтоб он не потерялся при обновлении версии Xcode.

                                                Ну вобщем я понял Вашу любовь к фреймворкам, окей, Вам так удобнее, вопросов нет.
                                      +1
                                      а Вы потом все ваши «драг-н-дропнутые» фреймворки храните в дереве исходных кодов вашего проекта? Кладете в vcs?

                                      Прелеть CocoaPods еще и в том, что в vcs достаточно хранить свои исходники, .*.xcodeproject и Podfile. Остальное материализуется на машине разработчика командой «pod intstall»
                                        +1
                                        или, еще хуже, используете git submodules для зависимостей?

                                        Простите, но у Вас все куда более костыльно, а Вы подаете это под соусом «более правильного» подхода.
                                          0
                                          >>> а Вы потом все ваши «драг-н-дропнутые» фреймворки храните в дереве исходных кодов вашего проекта? Кладете в vcs?
                                          в принципе, да. Я их обновляю нечасто. И да, я делаю это руками.
                                          Пока ни с чем сравнимым по размерам с boost под iOS не пользовался ==> vcs не рвался под их тяжестью.
                                          Для особо тяжелых зависимостей, подобных boost или three20 можно написать script, дергающий за xcodebuild в нужных местах.

                                          >>> Простите, но у Вас все куда более костыльно, а Вы подаете это под соусом «более правильного» подхода.
                                          Чую запах holy war
                                        0
                                        По сравнению с Nu Get для Visual Studio как-то блекло)
                                          0
                                          По сравнению с debian apt/aptitude тоже «как-то блекло»
                                          Для c++/objectiveC в этом вопросе повезло меньше чем интерпретируемым .NET, Ruby, Python.

                                          P.S.
                                          А с native кодом этот ваш NuGet умеет работать?
                                          >>NuGet is a free, open source developer focused package management system for the .NET platform
                                          скорее всего — нет.
                                            0
                                            >>А с native кодом этот ваш NuGet умеет работать?
                                            А за пивом ваш утюг умеет бегать?

                                            NuGet — штука для managed .NET, она как «дубель» — умеет что-то одно, зато умеет хорошо. Поэтому давайте без холиворов. Другое дело, что большинство авторов библиотек для iOS почему-то не хотят сделать последний шаг, а именно грамотно собрать библиотеку. Соглашусь с товарищем moborb — копипаста исходников в свой проект это не просто зло, а зло в квадрате. К сожалению действительно после разработки под .NET возникает ощущение вселенского бардака. Поэтому не стоит пропагандировать инструменты, которые способствуют разрастанию этого бардака. Авторы, делайте фреймворки и будет нам всем счастье.
                                              0
                                              >>> А за пивом ваш утюг умеет бегать?
                                              Зря вы так…
                                              .NET вполне отлично дружит с native code ( interop, DllImport и прочие радости ). Вот я и поинтересовался, насколько могуч предложенный вами инструмент. Вдруг ваш утюг и вправду можно было за пивком отправить. Эх, мечты-мечты…
                                              No offence, так сказать.

                                              Кроме того, у вас проблема зависимостей неплохо решена с помощью GAC. А NuGet, как я понял, качает, собирает и правильно все в этом GAC размещает.
                                              И это круто.

                                              Хотя во «вселенском бардаке» есть некое свое очарование и романтика.
                                                0
                                                Не ставит оно в GAC, за что авторам земной поклон, ибо dll-hell временами бывает почище того самого бардака (демонический смех).

                                                Меня поражает другое: за всё время работы с дотнетом, а это с ранних бет, я могу по пальцам рук и ног сосчитать случаи, когда компоненты поставлялись по принципу «скопируйте в папку и поправьте там внутри». А за свой недолгий сравнительно опыт написания под айдевайсы у меня уже нехватает рук и ног соседей по офису. Ввод в строй ARC вообще доставляет нереально, ибо теперь недостаточно просто скопипастить, частенько нужно идти и еще флаги компиляции выставлять (опять же вручную для каждого файлика, за что поблагодарим Xcode). Так вот, к чему этот крик души — что нужно сделать с авторами, чтобы они начали уважать тех, для кого они это разрабатывают?
                                                0
                                                да нет никакой «копипасты исходников в проект», их совершенно не обязательно хранить в vcs даже.
                                            +1
                                            Да круто, только жаль что так мало библиотек.
                                              0
                                              Можете добавить любую доступную библиотеку, даже свои приватные репы можно добавлять.
                                              Почитайте вики проекта.
                                                0
                                                Эта новость меня порадовала (йду смотреть что и как )
                                              0
                                              На вид все довольно просто, но мне кажется для управления зависимостями в проекте предоставляется слишком большая абстракция, делегирование управления и возможность загнать себя в рамки инструмента. Для меня субъективно конечно, но не очень уютно, когда я не могу в должной мере управлять всеми зависимости на любом уровне и использовать любой вид интеграции при этом не терять управление самим проектом в рамках общих правил (возможно это внешнее представление, но как мне кажется в любом случае я не убегу от дополнительной работы). Причем, желательно иметь возможность наглядно представить работу с проектом другому разработчику без лишней преподавательской работы по вниканию и представлению в скрытые правила и требования, которые используются текущей командой, но которые не видны наглядно либо не выясняются на первом этапе занкомства.

                                              Текущая используемая связка которая пришлась мне по вкусу: это хостить проект на том же github.com или bitbucket.org (у меня bitbucket с Mercurial -> свои критерии выбора), а для управления использовать такой замечательный инструмент sourcetreeapp.com. В котором и происходит управление самим проектом и зависимостями. Причем при использовании библиотек/фрейморков у меня есть правило всегда делать «fork» либо «branch» смотря под чем они хостятся, что позволяет мне вносить правки по своим требованиям в сторонние библиотеки, при этом ничего не теряя. Конечно в каталоге проекта есть соответсвующий каталог со всеми подключаемыми библиотеками/фрейморками. Кстати, не знаю как сложилось, но всегда пытаюсь подключать сторонние вещи только в виде исходников + писать тесты собственного на то, что использую из стороннего, чтобы быть в курсе о критических изменениях в сторонних вещам (которые сам не писал). В sourcetree собственно есть свой набор закладок для основного проекта и зависимостей к нему, что позволяет управлять каждым из них. На этом пожалуй и все, что касается моего управления проектами как OSX/iOS разработчика.

                                              Вопрос: кто какие связки еще использует для управления своими проектом и зависимостями внутри их? На самом деле очень интересно. Возможно мой вариант не самый удобный, подсказывайте свои буду рад узнать ваши приемы и инструменты на которые не обратил внимание, как на этот CocoaPods, про который слышал, но не попробовал даже использовать, почему не знаю.
                                                0
                                                делал как вы, сейчас пробую перейти на CocoaPods, все-таки каждый раз все руками апдейтить, пулить, пушить — задолбаешься. Ну и добавление библиотеки с зависимостями намного проще.

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

                                              Самое читаемое